Code In Review

Yep, I'm one of those people.? The kind of person who always puts my constants first in conditionals.? This was a learned habit, and not something that always comes naturally, but there are a couple of situations where if find it tremendously useful.? The prototypical situation is the ubiquitous null check:

?

I have always liked this check for the simple reason that I only need to read the first two words to figure out what it is doing.? Since I usually am skimming code looking for important bits, I can quickly discard this check unless I am looking specifically for NULL reference issues.? I find it much quicker to read since I only rarely care about which variable is actually being checked for NULL.

Of course, that construct pre-dates modern compilers and comes from “back in the day” when you could make assignments inside an if statement and have it still be a valid conditional:

This used to be a perfectly valid statement.? In this case, the if statement will always get executed (myFlag would be assigned true, which is then passed to the conditional, which would logically evaluate to true).? Of course, today's modern compilers will flag the original as a warning, and since we all compile with the Warnings as Errors flag set (you do, don't you?), these types of errors will never happen…? But still, many a long night was spent looking for “=” where we meant to write “==”…? So a number of developers learned to write it backwards:

Since you can't assign anything to a constant, the compiler caught this for us.? Not perfect, because you could still accidentally assign variables, but it was better.? This was why I originally began putting constants first in my conditionals.? I got bit by this error once, and my technical lead at the time introduced me to this pattern, for which I am eternally grateful.

Of course, for some reason, this always seems to annoy someone.? They claim that since the compiler will catch it, and it isn't a “natural” construction, that I should write it the “correct” way (which is always with the constant on the right).? In most cases, I am actually indifferent to coding style.? I am a firm believer that as a software professional you must learn to read a wide variety of coding styles because otherwise you will never be as productive as someone who can read any style (or at least the popular ones).? However, in this particular case, I much prefer my method.? The reason is simple…? It allows you to avoid needless NULL checks:

This method simply checks to see if a given name is mine.? Pretty simple right?? Return true if the name passed in equals mine.? Oh and since we don't know who is calling this, make sure that the name isn't NULL, and if it is return false, since my name isn't NULL.

Simple.? But wouldn't it be easier to just write it like this:

It does the exact same thing, only we don't need to bother with that pesky NULL check anymore.? The constant will never be NULL, so we can just test if the constant equals name, instead of the other way around.? It seems a little unnatural at first, but it avoids all sorts of unintentional errors (for example, how many people would have forgotten to check for NULL in the first example – I did the first time around…)??

Naturally, there are other ways to handle this and avoid having to test for NULL (String.Equals can handle null values), but this requires no framework support.? It will always work, and it has the added bonus that if you ever have to use a compiler that won't flag conditional assignments, you already use a defensive style of coding that won't expose you to unintended assignment errors.