As developers we tend to enjoy complexity; from obscure programming languages and data formats, to the lack of meaning in our variable names and other abstractions.

The purpose of this article is to encourage all of us to follow some basic principles.

The following are the basic principles to follow.

1. Avoid the "Is Not nothing" Pattern. I will illustrate what I mean with this simple conditional:
  1. if ( variable != false)
  2. {
  3. DoSomething();
  4. }
The test inside our parentheses could be rewritten with variable == true. Otherwise, the code will be confusing because we need to think somewhat deeply about it. The same thing happens when creating methods such as DoesNotExist(). Again, it is better to be straight forward and say something like DoesExist(). After all, isn't the point of code to be readable by humans?

2. Avoid Writing Unnecessary Code. This is something I see a lot in professional API's. Developers love to provide more constructor and method overloads than needed. Yes, it is true that some things should be flexible, but in reality, it is more code that one must read; not to mention it is somewhat pointless. Let's provide at least two or three overloads only; no more, no less.

3. Avoid Abbreviations. One cannot deny that production source files contain things such as "fu," "temp" and the annoying "numScores." This would be understandable if we didn't have tools such as code completion in our beloved IDE's, but we do. This means that we should utilize this to our advantage. Now, let's notice that I didn't say that we should not keep variable names short. I said that we should not have abbreviations included in variable names. For example, instead of naming our variable "numScores," why don't we name it "total," or "scores?"

I do believe that if we were to avoid the three things mentioned above, we could spend more time worrying about semantics and other aspects of our code, rather than having to battle with these little details that could slow down the development process. Your code should be self-documented and should be read elegantly.

If your code is elegant, you will stand out and you will shine as a developer.

Who knows; you might leave a legacy in your company if your code stands out.