uncategorized

Consistency through Convention

Code naming conventions are a very touchy subject. Many developers will get very defensive about ‘their way’ and will be quite offensive, or offended, by ‘your way’. In these posts I’m not going to try to change the minds of the easily riled. Instead I’m going to present options and opportunities with the hopes that they will be useful in the rare moments that developers are known to be lucid and open minded. I’m not going to pretend to be an expert who can pontificate on the subject. What I will do is present all of the different options that I know about and I will try to make fair comments on the good, the bad and the ugly of each.

Consistency in anything you do is important. As developers we strive for consistency in our build processes, user interfaces, architectures and coding practices. The primary reason behind the attempts at all of this consistency is productivity. To quote the Framework Design Guidelines book (Section 1.1.7 Well-Designed Frameworks Are Consistent) by Cwalina and Abrams:

      It (consistency) is one of the most important factors affecting productivity.

While Cwalina and Abrams tout consistency throughout their book, they do it with regards the benefits that it creates for the consumer (software developer) of a framework. I believe that the entire software development team (software developers, testers, maintenance programmers and framework consumers) can benefit from consistency.

Like the programming language itself, or the .NET framework, consistency in naming will abstract the details away from the programmer. If you know that all constructor parameters are named the same as the properties that they set, you will never hesitate or doubt. Good application of a standard will stop developers from having to make decisions when they are reading both their own code as well as code written by others.

In theory this lack of ambiguity will increase the productivity of all people involved. In practice the standard being enforced needs to be usable and readable. If I were to enforce a standard that said all integer variable names must consist of a single alpha character I would have a strong and reliable standard. The truth is that this standard, when left on it’s own, does more harm by decreasing the readability of code than it does good. Every area that is regulated by standards has a balance point where readability and consistency does not become onerous or counter productive. Standards that find this balance point are the ones that are adopted by large groups with ease and go on to live long lives.