I recently learned about the MISRA guideline and I am digging in. Thought I will share what I learned about it.
MISRA (Motor Industry Software Reliability Association) is a consortium formed in the UK automotive sector to publish best-practice coding guidelines for safety/security-critical software. It publishes coding rules that define a safe subset of the language so code behaves the same on every build and is easier to review and test.
It’s applicable for functional safety systems. Functional safety means a system stays safe even when parts fail. We design software so a single fault does not create danger. In cars, this aligns with ISO 26262. Other domains use similar safety norms.
MISRA helps by cutting out parts of the C or C++ language that are risky. These tricky parts can cause hidden bugs, memory problems, or code that’s hard to understand and test. This is a good fit for embedded systems that run for years. It makes reviews and tests sharper and gives auditors solid evidence.
It contains things for example, things like Use nullptr, not 0 or NULL. Avoid tricky casts like reinterpret_cast. Prefer smart pointers and RAII over new and delete. Do not return a pointer or reference to a local variable. Make destructors noexcept. Keep macros and globals small and controlled etc. Some 200 odd guidelines.
Current state for C++is MISRA C++ 2023 based on C++17 and influenced by AUTOSAR C++14. MISRA C 2025 exists for C. Official guideline is paid and for purchase(but cheap). The process guide MISRA Compliance 2020 is free and explains how to claim compliance, deviations, and reports. Also, AUTOSAR C++14 is free and still worth a read. Search around, you will find links talking about the guidelines in detail if you are tight on budget and not buying.
From what I understood, MISRA is not about creating zero violations. It is more about defining a clear coding process with justified deviations. I think I will start to use this more in firmware development from now on.
0 Comments
Comments are closed.