diff --git a/_posts/2021-06-14-new-book-code-that-fits-in-your-head.html b/_posts/2021-06-14-new-book-code-that-fits-in-your-head.html index dba9d75f..c07f3810 100644 --- a/_posts/2021-06-14-new-book-code-that-fits-in-your-head.html +++ b/_posts/2021-06-14-new-book-code-that-fits-in-your-head.html @@ -78,7 +78,7 @@

  • A restaurant example of refactoring from example-based to property-based testing
  • Decomposing CTFiYH's sample code base
  • Do ORMs reduce the need for mapping?
  • -
  • The case of the mysterious comparison
  • +
  • The case of the mysterious comparison
  • Some of these articles also use code examples from other sources, or code written specifically for that post, but whenever you see a code example from the restaurant reservation domain, it's from the book's code base.

    diff --git a/_posts/2023-09-14-the-case-of-the-mysterious-comparison.html b/_posts/2023-09-25-the-case-of-the-mysterious-comparison.html similarity index 96% rename from _posts/2023-09-14-the-case-of-the-mysterious-comparison.html rename to _posts/2023-09-25-the-case-of-the-mysterious-comparison.html index 44f544de..d73b940d 100644 --- a/_posts/2023-09-14-the-case-of-the-mysterious-comparison.html +++ b/_posts/2023-09-25-the-case-of-the-mysterious-comparison.html @@ -2,7 +2,7 @@ layout: post title: "The case of the mysterious comparison" description: "A ploeh mystery." -date: 2023-09-14 20:00 UTC +date: 2023-09-25 5:58 UTC tags: [Code] --- {% include JB/setup %} @@ -12,7 +12,7 @@ {{ page.description }}

    - I was recently playing around with the example code from my book Code That Fits in Your Head, refactoring the Table class to use a predicative NaturalNumber wrapper to represent a table's seating capacity. + I was recently playing around with the example code from my book Code That Fits in Your Head, refactoring the Table class to use a predicative NaturalNumber wrapper to represent a table's seating capacity.

    Originally, the Table constructor and corresponding read-only data looked like this: @@ -120,7 +120,7 @@

    First, if the immediate solution turns out not to work, you can waste much time trashing, trying various 'fixes' without understanding the problem.

    - Second, even if the resolution is easy, as is the case here, if you don't understand the underlying cause and effect, you can easily build a cargo cult-like 'understanding' of programming. This could become one such experience: All wrapper types must implement IComparable. + Second, even if the resolution is easy, as is the case here, if you don't understand the underlying cause and effect, you can easily build a cargo cult-like 'understanding' of programming. This could become one such experience: All wrapper types must implement IComparable, or some nonsense like that.

    Unless people are getting hurt or you are bleeding money because of the error, seek first to understand, and only then fix the problem. @@ -215,7 +215,7 @@

    Notice how the first line of code calls Schedule, while the rest is 'just' assertions.

    - Since I had noticed that OrderedEnumerable`1 on the stack I was on the lookout for an expression that would sort an IEnumerable<T>. The ScheduleImp method surprised me, though, because the reservations parameter is an array. If there was any problem sorting it, it should have blown up much earlier. + Because I had noticed that OrderedEnumerable`1 on the stack, I was on the lookout for an expression that would sort an IEnumerable<T>. The ScheduleImp method surprised me, though, because the reservations parameter is an array. If there was any problem sorting it, it should have blown up much earlier.

    I really should be paying more attention, but despite my best resolution to proceed methodically, I was chasing the wrong clue. @@ -400,7 +400,7 @@

    Deferred execution can confuse even the most experienced programmer. It took me some time before it dawned on me that even though the the MaitreD constructor had run and the object was 'safely' initialised, it actually wasn't.

    - The implication is that there's a 'disconnect' between the constructor and the Allocate method. The error actually happens during initialisation (i.e. in the constructor), but it only manifests when you run the method. + The implication is that there's a 'disconnect' between the constructor and the Allocate method. The error actually happens during initialisation (i.e. in the caller of the constructor), but it only manifests when you run the method.

    Ever since I discovered the IReadOnlyCollection<T> interface in 2013 I've resolved to favour it over IEnumerable<T>. This is one example of why that's a good idea.