Studies have looked at MISRA, I'm not aware of any for the JSF guidelines. For MISRA there's a mix, some of the rules seem to be effective (fewer defects in compliant software), some are the opposite (code which obeys these rules is more likely to have defects) and some were irrelevant.

Notably this document is from 2005. So that's after C++ was standardized but before their second bite of that particular cherry and twenty years before its author, Bjarne Stroustrup suddenly decides after years of insisting that C++ dialects are a terrible idea and will never be endorsed by the language committee, that in fact dialects (now named "profiles") are the magic ingredient to fix the festering problems with the language.

While Laurie's video is fun, I too am sceptical about the value of style guides, which is what these are. "TABS shall be avoided" or "Letters in function names shall be lowercase" isn't because somebody's aeroplane fell out of the sky - it's due to using a style Bjarne doesn't like.

For C, the proper/expected/standard way to reference a variable without accessing it is a cast to void:

    (void) a;

I've (unfortunately) written plenty of "safety critical" code professionally and coding standards definitely have a negative effect overall. The thing keeping planes from falling out of the sky is careful design, which in practice means fail-safes, watchdogs, redundancy, and most-importantly, requirements that aren't overly ambitious.

While maybe 10% of rules are sensible, these sensible rules also tend to be blindingly obvious, or at least table stakes on embedded systems (e.g. don't try to allocate on a system which probably doesn't have a full libc in the first place).

Zig makes it explicit with

    _ = a;

The standards don't remove the need for code review. In fact they provide a standard to be used in code review. Anything you can automate is nice, but when you have exceptions to rules that say "Exception, if there's no reasonable way to do X then Y is acceptable" isn't really something you can codify into static analysis.

You're right. MISRA is a cult. Actual studies[1][2] have shown many of their rules to be harmful rather than helpful. I have worked in multiple safety-critical industries. MISRA is almost always enforced by bureaucrats who don't understand source code at all, or by senior developers who rose up ranks as code monkeys. One such manager was impressed with Matlab because Matlab-generated C code was always MISRA compliant, whereas the code my company was giving them had violations. Never mind the fact that every function of the generated, compliant code had variables like tmp01, tmp02, tmp03, etc.

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...

An unused parameter should be commented out.

It’s very weird how none of the sibling comments understood what it were saying is wrong with this.

Especially since there is a widely recognized way to ignore a parameter:

    (void) a;

Isn't it inevitable for some cases of inheritance? A superclass does something basic and doesn't need all parameters, child classes require additional ones.