Re:The C++ standard for the F-35 Fighter Jet [video]
by sam_bristow on Monday December 08, 2025 @03:48AM
(#46189933)
One key point that people overlook with that paper is that they were applying the coding standards retroactively. Taking an existing codebase, running compliance tools, and trying to fix the issues which were flagged. I think they correctly identified the issue with this approach in that you have all the risks of introducing defects as part of reworking the existing code. I don't think they have much empirical evidence for the case where coding standards were applied from the beginning of a project.
In my opinion, the MISRA C++ 2023 revision is a massive improvement over the 2008 edition. It was a major rethink and has a lot more generally useful guidance. Either way, you need to tailor the standards to your project. Even the MISRA standards authors agree:
"""
Blind adherence to the letter without understanding is pointless.
Anyone who stipulates 100% MISRA-C coverage with no deviations does not understand what the are asking for.
In my opionion they should be taken out and... well... Just taken out.
- Chris Hill, Member of MISRA C Working Group (MISRA Matters Column, MTE, June 2012
"""
There are many areas of software where bureaucracy requires MISRA compliance, but that aren't really safety-critical. The code is a hot mess. There are other areas that require MISRA compliance and the domain is actually safety-critical (e.g. automotive software). Here, the saving grace is (1) low complexity of each CPU's codebase and (2) extensive testing.
To people who want actual safety, security, portability, I tell them to learn from examples set by the Linux kernel, SQLite, OpenSSL, FFMpeg, etc. Modern linters (even free ones) are actually valuable compared to MISRA compliance checkers.
[1] https://ieeexplore.ieee.org/abstract/document/4658076
[2] https://repository.tudelft.nl/record/uuid:646de5ba-eee8-4ec8...