Coding Standards and Naming Conventions
Wednesday, November 30, 2005
In our noble quest of engineering complex software applications, we have within our vast arsenal of tools, Coding Standards and Naming Conventions.
It seems obvious why organizations use them, but why should a group of highly trained engineers want to write uniform looking code?
It boils down to the following axiom:
The implementation of coding standards and naming conventions is an attempt to control quality.
According to statisticians and expert Quality Assurance professionals, including
W. Edwards Deming, quality control is not about building things to specification, but about controlling the variability of individual parts forming a whole system.
The idea of variability control leading to higher quality was first implemented in Japan after WWII. Statisticians brought to the devastated island new methodologies, which they claimed would aid in manufacturing industrial products with higher levels of quality. The experiment worked quite well, leading to a rapidly growing economy based on an unexpected manufacturing revolution.
At the time, North American business circles had the naive theory that Japanese manufacturing processes were better than North American's because of cultural differences, i.e., Japanese worked harder and better. We now know that their processes were better because they learnt to decrease variability in the smaller parts used to make bigger components.
When manufacturing physical components, it is easy to measure variability. For example, if we are building a car engine, we can measure all the parts in order to determine how each piece is different from an "ideal" designed standard. In this case, each piece is probably created with the aid of some kind of mold and automated machinery that make a copy of the model over and over again.
In software engineering, if we are to prove the statistical fact that less variability results in greater quality, we now have to figure out what "variability in lines of code" means. Specially, when every program ever written is different from each other.
When we build or
grow software, our working realm is the abstract and conceptual world. The executing parts of a system are ideas and processes that only exist while a computer is turned on. These abstract systems are put together by different types of minds with different experiences and competencies.
Not having molds to churn out lines of code, we try to reduce the variability of the code we write by implementing and enforcing coding standards and naming conventions. In other words:
by limiting the variability, we will have a better chance of maintaining and enhancing any particular program, regardless of its complexity or length.
The difference of executability and maintainability becomes key in the process, as writing code that compiles and runs at least once is easy - however, writing code to be maintainable is almost an art form.
Software applications are complex to design and implement. This complexity together with the ever evolving needs of users, make codelines non-static entities that must keep changing and adapting to new requirements.
Unfortunately, we can't physically open the hood of our J2EE banking systems and install new components at will. To maintain and modify a particular business rule, we must look at the whole system and figure out how the new change will affect everything else. Thus, by having standardized code styles and well known naming conventions, the task of maintaining any system becomes easier, as we can go back to the source and understand why certain algorithm has been written the way it was.
However, can we realistically expect our software engineers, who have vastly different experiences, to program identical looking and measurable lines of code?
Software Engineers come from an array of different backgrounds. If we give a particular problem to solve to a group of developers, we'd probably end up with as many solutions as there are engineers. The best we can do, I think, is to clearly explain why these standards are required and get the buy-in from our development groups. Enforcement levels will vary from organization to organization, but every company should implement coding standards and naming conventions.
I'm a big proponent of any Java shop to use Sun's
Java Coding Conventions. Most Java developers I know follow them, thus making it easy to come on board at any time or in situation with minimum training required.
Overall, the less variability there is in the lines of code we write, the better chance we'll have to successfully maintain any piece of software, no matter how complex it is. Moreover, the easier the maintenance phase becomes, the less
cost we'll incur fixing defects or adding new features to our ever evolving codelines.
Comments:
Checkstyle - enuf said !
Pick a code style for your project/group/company, review it frequently, enshrine the checking of it with an automated tool.
Very nice Jon...Thanks!