All shops have a coding standard. In many shops, the coding standard is not written down but is implicitly understood by the development team. And in a few shops, no one is cognizant that there is a standard. But there is always a standard, it’s just a matter of degree.
The loosest, most chaotic standard is that “everyone is doing Java,” but past that, everyone is on their own. From there, standards move up through concerns over formatting (where do the curly braces go?) to naming (no Hungarian notation!), to variant use of constructs (use the global import form), to general guidelines (methods should generally be no longer than 12 lines).
Whether your shop needs to recognize and adhere to stricter standards is a matter for your team to decide. In a purely emergent, evolutionary environment, the coding standard will mature out of consistent teamwork and continual review. When starting a new project, most teams will want to spend a few minutes to an hour discussing the things they are concerned about. Changes to the standard should be expected, as should exceptions to whatever the rules might be.
Why Standards?
What is the importance of a standard? One could argue that developers are a creative lot and should be allowed to code however they please. While this might be fine for a high-capability, hot-shot shop, it causes lost time and creates code that is more difficult to maintain.
Working with code that poorly or inconsistently adheres to standards is an aggravation that may not seem like such a big deal for the here and now. But the constant, low-level dissonance builds up into a nuisance over the course of your development day. Just as riding on a noisy road will make most people considerably more tired at the end of a day trip than riding over a smooth road, reading inconsistent code will wear you down more quickly. (I also suspect that if all code looks exactly the same, the monotony will wear you down as well. But if your code all looks exactly the same, you probably have a duplication problem…)
There is some corollary evidence: everything written about design and readability for web sites says that you don’t want to use more than a few font sizes, you generally don’t want to use multiple fonts, you should use a consistent and small color palette, each page should be consistently organized like each other page, and so on. Restricting designers to a reasonable set of consistency standards has in no way stifled the creative design of web sites. If this is true for web design, then it should also hold true for coding.
Arguments about formatting can often be resolved via use of most modern IDEs, such as Eclipse, that allow for automatic formatting of source code based on numerous settings. Individual developers can reformat code to their liking, as long as they check it in with the accepted standards after changing it.
But things like naming and organization cannot always be easily reconciled. If one developer uses Hungarian notation for modifications to a class that did not previously, the resulting code is a mess. If I have to look at the top of a class for the instance variables, while in another class I look at the bottom, and in yet another I have to look between the methods (urk!), the code does not consistently communicate things. Time spent understanding the code increases, and the likelihood of overlooking something important also increases.
Yes, tools (IDE) may help you reorganize and rename, but having to spend time to work with the tools do so is an additional investment with questionable cost. It’s a lot easier and cheaper to just get it right in the first place.
Developers should recognize that a coding standard is about consistent, clear communication more than anything else. If it’s not important to your shop to communicate ideas in a consistent fashion, tightening up your a coding standard is not essential. If you want one more technique toward bulletproof code, a better coding standard is a simple place to start.
