Coding Guidelines How-To (1st Thoughts)
For use in Safety or Security, a range of Standard Programming Guides is available. In automotive industry, MISRA and AutosarC++14 standards are widely used. While covering many different aspects, the standards leave it up to the user to define additional project or company specific rules.
As a first example, consider "Naming Conventions". Before actually running a check for rules, the rules should be properly defined, communicated, and agreed in the development teams. The degree of agreement depends on the respective work culture - but accepting the rules is key. Equally, a sound definition is key to acceptance.
To illustrate with an example, I analyse the following rule for Naming in the C programming language:
Rule NAMING-C-22: (1) Global names begin with a prefix that identifies the module unambiguously. (2) The prefix shall be written in all uppercase letters. (3) The Prefix must be separated by underscore from the remaining name. (4) The length of the prefix should not exceed 5 characters. Example: void LED_Set (void);
Simple rule? Not quite. As a reviewer of the rules, I have following remarks:
- Prefix is OK, unambiguous is OK. But what is a module? What exactly is the scope of global? Do we need a global analysis of all "global names" and all "modules"?
- Uppercase letters OK (we are talking ASCII, right?). Does this match a regexp like ^[A-Z]+?
- Looks OK, we just need to add `_` to the regexp.
- If the maximum is 5... what is the minimum? Is this check roughly `^[A-Z]{1-5}+`
- The example of the rule looks as if global names are specified for functions here. Where are the other types of artefacts? Are there additional rules? Is this one rule for all?
With having an automated check for Rule NAMING-C-22 in mind, I have to clarify the questions (and explain the consequences for the automated check).
To get more insights into my work at Axivion, register for our newsletter, visit our blog or follow us on LinkedIn and Twitter.