It can be tempting to dislike the MISRA Guidelines, or any coding standard really. Most people aren’t in a rush to be told how to do things. Ideally everyone reads the MISRA C document and sees the flexibility it allows while still preventing you from using the parts of the language that are ambiguous or undefined. But we have other important tasks to do, so we focus on the violations in front of us and rarely get around to reading the book. We still read blogs though, right? This first one is about the organization of the MISRA C Guidelines.

Just like the C language, not everything in MISRA C is fully defined. The guidelines are split into Directives and Rules. Rules are well defined, and most are statically checkable. Directives aren’t as self-contained; they send you off into the wild with an idea and some research or thought to figure out if the code complies. Static analysis tools can help you make the decision, but the choice is left as an exercise for the reader.
The guidelines are further organized into three categories: Mandatory, Required, and Advisory. They don’t rank the importance, but group guidelines by exceptions.

Advisory guidelines allow the most flexibility. As a category, advisory generally addresses violations that lead to confusion or reduce portability. They are all good practices to follow, but the Working Group that collated them understands that there are reasons to allow some room. Deviations are easy and don’t require a standard procedure, but it is recommended that they are documented for clarity (For example TBexclude). You can also upgrade these rules to required so that formal procedures are followed by default, which may make enforcement simpler and lead to fewer questions in the process. Project teams have the freedom to do so if they prefer.

Required violations can cause errors and they should be avoided in most cases. They require a formal deviation process; each one needs to be documented, but the exact process is up to the project or company. Allowing for deviations means that it is reasonably flexible, but you must feel strongly enough about it to go through the process. Sometimes, a particular construct or practice is sufficiently well used and understood for there to be little risk in using it, even though it represents a guideline violation. Exceptions or deviations from hard and fast rules allow the flexibility to accommodate such circumstances without compromising the goal to make things as predictable and well understood as possible.

Mandatory guidelines leave no such room for deviation. You are required to follow them as written. There aren’t many and they address practices that will cause errors. Most of these are designed to avoid the traps that developers can fall into when unaware of the risk. I struggle to come up with an argument for any deviations from these that would make sense.

While there aren’t exceptions for every rule, they clearly provide enough versatility for the MISRA C Guidelines to have become the standard of choice for more than just the automotive industry. The writers were pragmatic about the idea that every situation is going to be different and the limited ability to configure the Guidelines to the project strikes a nice balance between “do this” and “do what you want”.

Before I came to LDRA I worked for a medical device company that was beginning to adopt MISRA C, and they gave me the opportunity to highlight a guideline each day for months. The low-pressure chance to read and understand a rule sparked questions and conversations, and that discussion changed the way we were writing code. Understanding the concepts eased the pain of “Why do I have to fix this?” as well as preventing some violations in the first place, which accelerated the compliance process.