Consistency

The more programmers I work with and the more code I read, the more I realize that everyone has their own unwritten style guidelines in their head for writing code. Some people are more self-consistent than others in their implementation of their style guidelines but it seems that most people at least have some semblance of coding guidelines that they follow. This is expected behavior as programmers come from different backgrounds and experience levels. In and of itself, this isn’t a big problem.

Unfortunately, it becomes a big problem when you form teams of programmers because just like an essay written by multiple authors, it becomes difficult to get past the style issues of multiple programmers in the same codebase. A team should write code that is self-consistent across the team. This provides several benefits, among them a greater understanding of a common codebase, easier pair programming and code reviews, and less frustration for current and future maintainers of the codebase. When you form teams with no guidelines for coding style, you get a mishmash of sytles that becomes increasingly frustrating for everyone involved. If you have to maintain a large codebase written by a team without coding standards, you’ll quickly grow tired of trying to remember whether programmer A liked to prefix or suffix TextBox on all his text boxes or if in this class the private variables have underscores or not.

Coding standards are one of the skeletons in the closet for software developers. Most developers scoff at implementing them, chafing at the concept of having to bend their style to a common one. That’s too bad because it’s a big drag on productivity on teams larger than 1. Look, I love regions as much as the next guy but that doesn’t mean I can’t easily alter my “style” to avoid regions in the code I write for the benefit of consistency. It’s a joy to read a codebase that is self-consistent whether it was written by 1 developer or 50 because you don’t have to spend any cycles trying to remember what an underscore means or expanding regions in one class but not in another or searching for private fields at the top of a class or at the bottom or wherever the developer felt like declaring them.

For consulting companies, I’d think it would be a competitive advantage to have coding standards defined for the organization. When hired by clients that didn’t have their own standards, a common standard for consultants would result in teams that were more productive as well as clients that were happier in the maintenance of the codebase. On top of that, if different consultants from the same company eventually came out for a followup, they could come up to speed more quickly because the codebase would be organized in a consistent manner. A final benefit would be from a sales perspective. Being able to say that all code on all projects written by a company was consistent to the same style regardless of which consultants participated would show prospective clients that all consultants with the company operated as if on the same team and valued a common set of standards.

Emerson wrote “A foolish consistency is the hobgoblin of little minds” and he was certainly right. Consistency in coding standards isn’t foolish though and adds plenty of happy side effects to teams that write from the same standards. It’s a shame more developers and companies don’t understand this.