9 Best Practices for Using Coding Standards
Coding standards are guidelines. They ensure safe, secure, and reliable code. And they’re often required to comply with a safety or security standard.
Coding Standards Best Practices
Here are our top nine best practices for using coding standards effectively.
1. Know Why You're Using It
A coding standard’s purpose is to restrict use of problematic areas of the programming language.
So, using coding standards prevents undefined or unspecified behavior. And it limits the use of error-prone constructs, such as "goto".
And using coding standards also improves the code’s readability, maintainability, and portability. One example is the use of “typedef” to simplify the syntax of complex structures. This reduces overall cyclomatic complexity.
2. Choose the Best Coding Standard For Your Industry
The coding standard must be recognized and accepted by the industry for which it is being used. Choosing one recognized by your industry is extremely important. It reduces the amount of qualification work to satisfy your end users.
A good example is MISRA C and C++. These were written for the automotive industry and have since become the de facto standards for safety-critical applications. They're recognized as one of the best coding standards for embedded industries.
3. Use Coding Rules and Follow Recommendations
Coding standards usually include two elements — rules and recommendations (or directives).
Rules are the backbone of a coding standard.
Code compliance is normally defined in term of rules. Modern rules are often stated in such a way that makes it easy to verify them with a static analyzer. For example, the rules are “statically enforceable”.
Recommendations (or directives) are usually advisory.
It’s up the engineer whether to follow them or not. Normally they do not impact compliance. They usually aren’t statically enforceable.
Most coding standards have both rules and recommendations. However, some coding standards only have rules — such as ISO/IEC TS 17961: 2013 C secure coding rules and MISRA C:2004.
4. Describe the Intent Behind the Rule
Each rule should have an identification string, a headline, and a description.
The identification string identifies the rule. For example, “Rule 10.3” or “EXP30-C”.
The headlines summarize the intent of the rules. For example, “There shall be no dead code” or “Freeing memory multiple times”.
The description elaborates on the headline and provides suitable context.
The description can also discuss how it is applied. For example, whether it can be assessed by analyzing a single transaction unit or the entire project.
And it could include code examples of compliant and noncompliant behavior — and exceptions to the rule.
5. Update Coding Standards With Care
Frequent updates to a coding standard may not be a good thing. This is especially true in safety-critical applications where long lifecycles are the norm. And these industries tend to be suspicious of using new language constructs that have not yet been proven reliable.
The sequence of updates to the MISRA standard is a good example of having significant delays between each version. C99 was finalized in 2011. But it wasn’t until 2013 that MISRA C: 2012 updated the standard to C99. And MISRA C++ — published in 2008 — marked the update to the 2003 version of C++.
6. Consider Open vs. Closed Standards
So, CERT puts the emphasis on community cooperation. The result is a coding standard in the form of an open, freely available web-based wiki. Users can comment on single guidelines. These comments are considered when the guidelines are reviewed.
MISRA is developed through working groups that create and update standards according to a pre-decided roadmap. This top-down model leads to the work not usually being publicly available. There is normally a price to pay, which helps cover the expenses of the working group. However, MISRA is influenced by community feedback, too.
The main difference between open versus closed standards is how quickly they change.
Open standards tend to be extremely dynamic. Guidelines change quickly. Closed standards, however, are better for safety-critical industries. They provide a stable reference to meet mandatory requirements.
7. Prioritize Coding Rules
When you check your code against a coding standard, you might get a wall of bugs. Categorizing the rules with a severity matrix helps you assess code quality and prioritize bug fixes.
Assessing the code quality helps you decide whether to move into production. If there are major problems, it’s not ready. If the problems are minor, then maybe it can go into production and be fixed later.
Defects need to be prioritized so the high severity ones are fixed first. This is particularly useful for coding standards with many rules.
8. Plan for Rule Deviations
Coding rules don’t fit all situations. There will always be deviations.
The three key factors for planning for rule deviations:
- Decide which guidelines can be deviated from and which cannot
- Specify how a deviation can be done properly
- List what needs to be documented or recorded when a deviation takes place.
Having a plan for rule deviations will help you if you need to provide evidence to an auditor.
9. Educate Programmers
One of the goals of coding standards is to educate programmers. And supporting material to a coding standard can provide that education.
Supporting material helps the programmer understand the background or give extra information for those who want a more detailed knowledge.
For example, this might include links to documentation such as ISO standards and books. Or there might be references to other coding standards or reports of real-world problems caused by violations of the guidelines. There might also be information on risk mitigation actions or solutions to specific problems.
Choosing the Best Coding Standards
So, how do you choose a coding standard?
You can use these coding standards best practices as a starting point. The next step is to evaluating coding standards based on your needs.
For instance, the embedded systems industry primarily uses C and C++ programming languages. There are several coding standards that support these languages — and each one is different.