[time4tea]

a = a; // misra

Actual code i have seen with my own eyes. (Not in F-35 code)

Its a way to avoid removing an unused parameter from a method. Unused parameters are disallowed, but this is fine?

I am sceptical that these coding standards make for good code!

[tialaramex]

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.

[platinumrad]

The "good" rules are like "don't write off the end of an array", and the bad ones are like "no early returns" or "variable names must not be longer than 6 characters". 95% of the "good" rules are basically just longer ways of saying "don't invoke undefined behavior".

[windward]

Bjarne's just a guy, he doesn't control how the C++ committee vote and doesn't remotely control how you or I make decisions about style.

And boiling down these guidelines to style guides is just incorrect. I've never had a 'nit: cyclomatic complexity, and uses dynamic allocation'.

[writtiewrat]

[flagged]

[unwind]

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

    (void) a;

I'm sure there are commonly-implemented compiler extensions, but this is the normal/native way and should always work.

[amluto]

Not if you use GCC.

https://godbolt.org/z/zYdc9ej88

clang gets this right.

[platinumrad]

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

[dilyevsky]

Many coding standards rules have nothing to do with correctness and everything to do with things like readability and reducing cognitive load (“which style should I use here?”)

[ivanjermakov]

Zig makes it explicit with

    _ = a;

And you would encounter it quite often because unused variable is a compilation error: https://github.com/ziglang/zig/issues/335

[bluecalm]

Doesn't it make it more likely unused variables stay in the codebase? You want to experiment, the code doesn't compile, you add this (probably by automatic tool), the code now compiles. You're happy with your experiment. As the compiler doesn't complain you commit and junk stays in the code.

Isn't it just bad design that makes both experimenting harder and for unused variables to stay in the code in the final version?

[ErroneousBosh]

Golang is exactly the same.

It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.

[y1n0]

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.

[msla]

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

    (void) a;

Every C programmer beyond weaning knows that.

[time4tea]

The point really was that the unused method parameter should in almost all cases be removed, not that some trick should be used to make it seem used, and this is the wrong trick!

[stefan_]

I'm sure thats disallowed for the C-style cast.

[qart]

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

[sam_bristow]

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

"""

[jojobas]

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.

[jjmarr]

An unused parameter should be commented out.

[MobiusHorizons]

Unless it’s there to conform to an interface

[binary132]

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

[binary132]

Erm, sorry about the weird typo. Didn’t notice. Can’t edit now.