Styles, Standards and Conventions

Does it really matter how the code is formatted? Does it matter how you name the variables? Does it make a difference which variations of syntax you utilize for common tasks like loops?

For the most part any particular style, standard or convention is arbitrary. Sure, there are some that reduce or enhance the readability -- look at the obfuscated C contest for excellent reduction examples -- but overlooking the small trade-offs they all pretty much do the same thing. They set up some consistency in an otherwise unrestricted language environment. This doesn’t really matter to the computer, it has no sense of readability and it functions nearly identically no matter how the code is typed in.

So should programmers be free to create their code in any personalized or distinctive manner? Nope. We can not undervalue the utility in being able to easily read code, or in being able to spot obvious bugs because of how they violate consistency or naming conventions. A single file of code that is badly formatted, poorly named or bounces between different styles can easily hide bugs that would be obvious if the time and care were taken to add consistent formatting and naming. No one likes to waste time looking for problems that should be obvious, so that little bit of extra time and effort taken to make it clean easily pays off both in the short run, and over time.

Should a team of programmers all adopt the same style? Absolutely. Bugs are an indisputable fact of programing. Most systems are large enough, and complex enough, to require multiple people all working together. If one section of code is so eclectic that it prevents others from accessing it, it may work at the execution level, but it fails to be part of the system. And one is often blind to their own obvious coding flaws, so encouraging a second or third pair of eyes to help spot inconsistencies easily saves valuable time.

Job security is an often joked about excuse for excessive variations in styling, but it is far less stressful during vacations to know that any immediate problems can be solved by other people. It isn’t long before people notice that someone’s lack of presence means no progress, which generally builds up resentment. Pissing people off isn’t a very intelligent way of providing security (and never works in the long run).

An artistic desire for creative expression is another common motivation for group inconsistencies. That speaks to the idea that programming isn’t engineering and that the byproduct is a form of art. That may be true for some funky demo, but for serious projects one needs well thought-out industrial strength code. Failure to get this always means that the increasing acts of patching problems that were avoidable always grows large enough to consume any new efforts to extend the system. A mess begets a mess, and eventually eats up all of the time to do anything else. Thus ‘the art’ blocks out the ability to continue to build things. Creativity is nice, but getting something actually built is far better.

Styles, standards and conventions are a project/code-base specific issue. For each code-base (how ever large you want to define it) all of the programmers on the teams that are contributing to it, should follow the same rules as closely as possible. No excuses, no exceptions.