Think ahead about coding standards
If your product doesn’t need to meet a specific industry or international process standard—such as those for safety-critical software in avionics, defense, or medical applications—why would you consider a coding standard? After all, coding standards such as MISRA, CERT C, CWE, and the Embedded C Coding Standard may prevent you from using C or C++ features that are designed to make your work easier or more efficient, or that provide work-arounds for obstacles.
But sometimes those features are exactly what get programmers into trouble by allowing coding errors. These errors that ultimately add significant development or support costs to your product and slow time-to-market. By meeting the requirements of a coding standard or language subset, the advantages you gain in better quality code, reduced paperwork and rework, and higher product reliability can more than offset any perceived disadvantages. The key is to make the coding standard decision early in the development process and identify a configurable, automated tool to make it easy for your development team to verify and enforce the standard.
Figure 1: A selection of some of the popular standards, including MISRA C, MISRA C++, CERT C, and the Embedded C Coding Standard
What can coding standards do for you?
Coding standards are a collection of programming guidelines or requirements that help ensure that the quality of attributes of a project are appropriate to its integrity level. While standards may be best known for helping programmers meet stringent quality requirements for safety-critical applications, code quality can make or break product success in a wide range of applications. For example, code errors in non-safety-critical automotive systems can result in enormous support costs because of the volumes involved and the overhead for recalls and upgrades, not to mention the product brand devaluation caused by a widely publicized programming defect.
Coding standards protect programmers from errors that can be introduced due to weaknesses in the C or C++ language or from human oversight. Both can easily occur in today’s fast-paced development environments that include large programming groups developing complex software in dispersed locations. Essentially, coding standards provide a foundation for programming best practices.
Compliance with programming standards helps developers:
- Promote portability and avoid unexpected results
- Avoid reliance on compiler- or platform-specific constructs
- Identify unreachable or infeasible code, which can indicate a defect that could impact software maintainability
- Prohibit certain language constructs known to be a source of common errors.
- Measurably reduce program complexity
- Improve program testability
- Reduce long-term support costs due to coding errors
The implementer of a coding standard has to balance the strictness of the guidelines against the effort required to follow them. Coding standards used within a formal-methods environment often contain “absolute” guidelines that may never be violated. On the other hand, while it may be desirable to have strict enforcement of a coding standard, it’s not always practical; some products can effectively use a subset to better meet project cost, reliability, and safety requirements. For example, the C programming language contains many implementation-defined behaviors that generally should be avoided, such as using the absolute position of bits within a bit-field, but whose use is essential under certain conditions, such as when mapping onto hardware registers.
A coding standard needs to allow some flexibility so that guidelines can be violated in a controlled way. Decisions around flexibility and tradeoffs should be made early enough that deviations can be analyzed and determined and rules established that define appropriate use of that deviation by the project team.
Is a subset acceptable?
It’s important to determine early in project planning whether a subset is permissible and to identify the guidelines that are to be excluded from the full standard. The first step is to understand certification requirements.
Many projects are expected to adhere to an international industry-specific standard such as ISO 26262 for automotive or IEC 62304 for medical systems, especially if those projects have high-integrity requirements. Certification of compliance will either be via a certification authority or by means of self-certification. These international standards generally require the use of a language subset defined by a coding standard. If a project needs to be certified before it is put into service, then the requirements laid down by the certification body will be a primary driver. A specific coding standard may be mandated, one may be chosen from a set of approved standards, or the choice may be left to contractual arrangements. The certification body may further restrict what sub-setting is permitted or may prohibit it entirely, especially if compliance with an approved standard is formally verifiable.
The process is slightly different when there is no requirement for certification prior to deployment. When a certification body is not involved, the project may have more flexibility to decide if it is appropriate to use a subset of a coding standard, especially when the safety requirements are less stringent. You’ll also need to determine whether the chosen coding standard permits a subset to be used and whether the supply contract allows the use of a subset. As with all decisions related to the standard, these should be addressed as early as possible in the design cycle to avoid code rework or the need for excessive documentation to back up later decisions.
In many cases, companies have developed their own internal coding standards and guidelines to support programming efficiencies, establish consistency, and improve code readability and maintenance within development teams and over the life of the product. These internal standards might also include a combination of other standards or subsets.
Currently no items