This is a leading question, but it's actually easy to achieve if you haven't yet started using automated checkers for coding standards. By using e.g. a MISRA C checker, that happens to be built into IAR Embedded Workbench, you cannot only make your applications safer by avoiding dark corners of the C standard, but also significantly increase the general quality of your code base with a relatively small effort without needing to have the ambition of becoming fully MISRA C compliant.
Seeing the long lists of rules can easily turn you away from trying to implement a coding standard. You might think that there is no way you can apply all these rules in your projects with a reasonable effort – and Yes, that is probably true for existing projects. And how many projects start from scratch today? However, you can use the checker with a very limited number of rules, even only one of them, and get an immediate raise of quality in your code base.
Enabling individual rules is simple in IAR Embedded Workbench: Go to [Project] =>[Options] =>[General Options] =>[MISRA C tab]. Click on 'None' to clear all default selections of required rules, and then select the individual rules you want to use.
To start with, I propose selecting "easy" rules that will help you and your team code in a more similar, and better, way. One simple example is the rule "The statement forming the body of a switch, while, do ... while, or for statement shall be a compound statement". Applying this rule will not only make the code easier to read, but it will also be safer from a classical mistake, which is easy to do when you are in a hurry;
Another simple example is the rule "Source code shall only use /* ... */ style comments", which could be debated as such, but for sure when used will give a conformity of code comment style throughout the project team and your code base.
There are a number of useful rules related to how you declare and define objects and functions to make things clear, like "There shall be no definitions of objects or functions in a header file" and "Functions shall have prototype declarations and the prototype shall be visible at both the function definition and call".
The rules also deal with arithmetic type conversions such as "Conversions shall not be performed between a pointer to a function and any type other than an integral type", as well as control flow rules such as "There shall be no unreachable code".
Under [Help] =>[MISRA C Reference Guide] within IAR Embedded Workbench, you’ll find all the rules explained.
The built in MISRA C checker in IAR Embedded Workbench is a very powerful tool in a programmer’s toolbox. By having an approach where you select a few rules to start with, you can raise the quality of your code base dramatically with a small effort.
This article is written by Thomas Sporrong, Global FAE Manager at IAR Systems.