- Introduction
- Creating a Set of Guidelines
- Example Guidelines
- Adhering to Guideline Recommendations
- Costs and Benefits
- The Future
Adhering to Guideline Recommendations
Adhering to coding guidelines is an investment. This investment is made in the hope that benefits will be received later that are greater than the costs of adherence.
Two methods for helping ensure that guidelines are adhered to are developer training and automated checking of the code. If developers are aware that use of some construct is likely to be a cause of faults, they can avoid its use, with automated checking flagging those instances that developers overlook. One of the reasons that converting existing source (to make it adhere to a set of guidelines) is so expensive is that the authors of the code were unaware of the guidelines that needed to be followed and made frequent use of constructs that violated these guidelines.
Using tools to check adherence is obviously cheaper and less error-prone than having people do it. However, current tool technology has limitations and some guideline documents contain requirements that currently can be performed only by people (for example, "Identifiers shall have meaningful names"). Requiring that it be possible to check adherence to all guidelines using tools simplifies their enforcement. However, this approach leaves a whole class of known problem constructs outside the scope of a coding guideline document. Guidelines whose enforcement requires checking and evaluation by people are normally handled during code review.
It’s important to appreciate that sometimes situations arise in which it’s necessary to make use of a construct that some guideline recommends against. Experience shows that management is generally willing to sanction violations of guideline recommendations if the need arises. (The term deviation is used to describe these exceptions.) The potential problems are not necessarily caused by the violation itself, but by the fact that occurrences of violations are often hard to locate and, when discovered, their existence can come as an unpleasant and perhaps costly surprise. A deviations mechanism balances the possible harm that a permitted guideline violation might cause against the benefit of allowing it to occur but requiring that the usage be explicitly documented, so that others can easily locate all deviations from guidelines and verify that the decision made was appropriate.
People sometimes interpret the same specification in different ways. Experience with tools that check source for adherence to the MISRA-C guidelines, for example, shows that some tools use widely differing interpretations; in the case of MISRA-C, the wording of a significant number of the guidelines is ambiguous, which has allowed tool vendors to interpret the requirements in a way that’s consistent with the existing behavior of their tools. The solution adopted to measure compiler conformance to a language specification is to use validation suites. In the case of some popular languages such as C and C++, enough commercially available compilers have been written to make it economically viable for third parties to write and sell compiler test suites. When these suites are used by official standards-conformance testing laboratories, they’re called validation suites. While there are more than a half-dozen tools claiming to check code for adherence to the MISRA-C guidelines, there is currently no third-party test suite for these tools, although a few people have produced a small selection of tests.