

Basic Patterns for Everyday Programming - laktek
http://laktek.com/2011/11/23/basic-patterns-for-everyday-programming/

======
mrspandex
Checking for null on every method invocation? I usually call methods for a
reason and if my object is null, I have an error. If I have a situation where
an object may be null, there will be specific handling for that case.

The other "patterns" are fishy too. How has this gotten so many points?

~~~
jwdunne
The author's response to a comment destroys the article's credibility by
saying the difference between '==' and '===' is purely stylistic. I think
somewhere down the line the author started to run before he could walk and
that'll definitely come back to haunt him.

~~~
laktek
I have never claimed the choice between '==' and '===' is stylistic.

------
damncabbage
The tucking-away of _current_date_ and _current_day_ inside _discount_day?_ is
a mess. If either change between calls to _discount_day?_ , suddenly
_discount_day?_ is returning the wrong value. That method returns different
values given the same inputs; it's not a good candidate for being memoized.

(Furthermore, it's harder to test, as now _current_date_ and _current_day_
need to be stubbed out. It's also less obvious which day is being checked with
regards to being discount day or not.)

I'd recommend having _discount_day?_ taking a date as the argument, and having
it invoked as _discount_day?(current_date)_. (The day can then be calculated
from the provided date.)

------
adammacleod
I'd be careful with the last Memoize example, if current_date changes then the
JavaScript function at least will return the old value still.

Memoize only works if your function is one to one (one set of inputs gives the
same outputs), and you cache the result of the function for each value of the
input.

~~~
evmar
The last example also doesn't actually memoize if the result of the
computation is false -- it will recompute on each call.

~~~
adammacleod
It will store a false in the JavaScript version, I'm not familiar with Ruby
but I believe you are correct in that case.

------
erez
One pattern that this guy misses is "better to be clear than to be clever".
His "a == x || a == y..." example is a case of verbosity being a good thing,
and probably the reason why most languages don't have a == (x or y or z) in
their syntax. And then, if this isn't convoluted enough, he hides it behind an
abstraction, which is another anti-pattern: Whatever you need to hide, you
need to refactor. Hiding your cleverness away from the user is never a good
idea. He even excuses it with "This refactoring allows others to read the code
in context to the domain, without having to comprehend the internal logic."
Sadly, this "Don't make me think" attitude is very common.

~~~
morsch
He proposes to replace

    
    
       if(current_day == "Monday" || current_day == "Wednesday" || current_day == "Friday") 

with

    
    
       if(["Monday", "Wednesday", "Friday"].include?(current_day))
    

I've done this before, and I don't think it's any less clear -- I wouldn't
have thought of making a public announcement about it, though. I like it
because it more closely aligns with the way you're probably thinking in this
example: you're wondering if _current_day_ is part of a certain set of days
(the discount weekdays, apparently), not if it's equal to "Monday" or equal to
"Tuesday", etc. I like the Javascript example with it's _indexOf(..) >= 0_ a
lot less, but I guess people more used to JS idioms auto-translate this
sequence to a set-contains operation.

It's more sensible if the set of values is larger than just three; and in this
instance, you have to wonder why the day isn't available as a numeric
variable, but I think you can let it slide for a contrived example.

It's even more useful if you reference the same set more than once, because
you can just define it once, and as a constant if your language of choice does
that kind of thing. This would also let you make your code less wordy (but
arguably more literal) without hiding logic in functions, e.g. his later
example would be

    
    
      if(discount_weekdays.include?(current_day) && current_date > 20)

~~~
Inufu
So like Python's 'in'?

    
    
      if 5 in [1, 2, 5, 6, 8]:
          pass

------
Jach
Memoization is an optimization technique, I certainly don't use it every day.
Be sure you verify you actually get a speedup (especially when using hash-
tables for your cache) before you run off and prematurely optimize, as well as
understand the trade-off of increased memory and less computation (if it's an
actual speedup). As others have pointed out the example of memoizing in the
blog is pretty bad. Storing the value in a variable seems like a better choice
than in a procedure to me, if your program won't be running over a day.

------
DanielRibeiro
Cool. Looks a lot like an excerpt of Smalltalk Best Practices[1] and a bit of
Refactoring[2] book together.

[1] [http://www.amazon.com/Smalltalk-Best-Practice-Patterns-
Kent/...](http://www.amazon.com/Smalltalk-Best-Practice-Patterns-
Kent/dp/013476904X)

[2] <http://martinfowler.com/books.html#refactoring>

------
Yrlec
If you want to use memoization for caching in C#, you can try out my library
FuncCache: <https://bitbucket.org/Yrlec/funccache/overview>

------
ericflo
I love the design on this blog.

