How we change what others think, feel, believe and do
CHAPTER 1 : Standards
1.4 What are coding standards for?
Translating the manufacturing reasons for standardization into factors for consideration in coding standards results in several clear reasons for standardization:
Productivity in the writing of code means saving time (not only in the original coding, but also in future support and maintenance), without incurring a penalty in quality. Thus it must be:
Toolable If available tools can be properly used, then this may reduce human effort on the program.
Portable Portable code is easy to translate to other software and hardware platforms. Non-standard code is likely to be non-portable too.
Reusable If a section of code can be re-used, then the entire time to write it is saved each time it is reused. Note, however, that the quality of the code is reused too. Any problems in the code will be multiplied by reuse.
The quality of the code lies in its conformance to specification (assuming, of course, that the specifications are correct). Thus it must be:
Testable Consistent and simple code results in good tests which are easy to write. Complex code requires complex tests which are often still incomplete.
Reliable Reliable code holds no surprises. It has few defects, and any problems are handled consistently and gracefully.
It must be possible for other programmers to maintain and use the code. Thus it must be:
Enhanceable To add new features to the code requires that it can be understood and has no tricky interfaces.
Fixable Fixable code is not only easy to understand, it also helps the maintainer by providing diagnostics to locate the problem area (error messages, core dumps, etc.).
To be able to do all of the above, the code must be understandable. This means that it must be:
Consistent The way things are done should be the same throughout the program. This applied to usage of programming constructs and to the layout of the code.
Communicable To understand code, it must be easy to read and to explain. To pass ownership of code to someone else (e.g. a maintenance programmer) it must be both explainable and self-explanatory.
Coding standards address all of the above points either directly, for example where they recommend portable usage, or indirectly, for example where use of them results in more reliable code.
And the big