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!
(void) a;
_ = a;
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.
https://godbolt.org/z/zYdc9ej88
clang gets this right.
It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.
Isn't it just bad design that makes both experimenting harder and for unused variables to stay in the code in the final version?
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).
I doubt I can satisfy you as to whether I'm somehow a paid evangelist, I remember I got a free meal once for contributing to the OSM project, and I bet if I dig further I can find some other occasion that, if you spin it hard enough can be justified as "payment" for my opinion that Rust is a good language. There was a nice lady giving our free cookies at the anti-racist counter-protests the other week, maybe she once met a guy who worked for an outfit which was contracted to print a Rust book? I sense you may own a corkboard and a lot of red string.
I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?
I do early returns in code I write, but ONLY because everybody seems to do it. I prefer stuff to be in predictable places: variables at the top, return at the end. Simpler? Delphi/Pascal style.
There is an element of taste. Don’t create random early returns if it doesn’t improve the code. But there are many, many cases where it makes the code much more readable and maintainable.
When my database logging fails, I write a file that logs the database fail (but not the original log file).
When my file logging fails, depending on application, I'll try another way of getting the information (the fact that for file logging failed) out - be that an http request or an email or something else.
Databases fail, file systems fill up. Logging logging failures is extremely important.
I like to have a separate monitoring process that monitors my process and a separate machine in a different datacenter monitoring that. But at the end of the day, the first process is still going to do try to log, detect that it failed, try the final backup log and then signal to its monitor that it’s in a bad state. It won’t make any decisions that depend on whether the final backup logging succeeds or fails.
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...
It might be a good guideline.
Its not a good rule because slavishly following results in harder to follow code written to adhere to it.
For example of the rule, a function might allocate, do something and then de-allocate again at the end of the block. A second exit point makes it easy to miss that de-allocation, and so introduce memory leaks that only happen sometimes. The code is harder to reason about and the bugs harder to find.
source:
> A problem with early exit is that cleanup statements might not be executed. ... Cleanup must be done at each return site, which is brittle and can easily result in bugs.
https://en.wikipedia.org/wiki/Structured_programming#Early_r...
About 90% of us will now be thinking "but that issue doesn't apply to me at all in $ModernLang. We have GC, using (x) {} blocks, try-finally, or we have deterministic finalisation, etc."
And they're correct. In most modern languages it's fine. The "no early returns" rule does not apply to Java, TypeScript, C#, Rust, Python, etc. Because these languages specifically made early return habitable.
The meta-rule is that some rules persist past the point when they were useful. Understand what a rule is for and then you can say when it applies at all. Rules without reasons make this harder. Some rules have lasted: we typically don't use goto at all any more, just structured wrappers of it such as if-else and foreach
It's kind of like the olden days.
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
It's a slightly different mindset, for sure, but having gofmt bitch about stuff before you commit it rather than have the compiler bitch about it helps you "clean as you go" rather than writing some hideous ball of C++ and then a day of cleaning the stables once it actually runs. Or at least it does for me...
And boiling down these guidelines to style guides is just incorrect. I've never had a 'nit: cyclomatic complexity, and uses dynamic allocation'.
Comments like yours are difficult because they’re not actionable or able to be responded to in a way you’ll find satisfying if you don’t link to the comments that you mean.
Programming language flamewars have always been lame on HN and we have no problem taking action against perpetrators when we’re alerted to them.
My memory might be lapsing here, but I don't think MISRA has such a rule. C89/C90 states that _external_ identifiers only matter up to their first 6 characters [1], while MISRA specifies uniqueness up to the first 31 characters [2].
[1] https://stackoverflow.com/questions/38035628/c-why-did-ansi-...
[2] https://stackoverflow.com/questions/19905944/why-must-the-fi...
In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them.
> Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.
I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable).
This BTW this happens more often than you would expect. I have read PRs and had to reject them because I read the code and they wouldn't have worked, so I know the person had never actually run the code.
I am quite a tidy programmers, but it difficult for people even to write commit messages that aren't just "fixed bugs".
This BTW can cause issues with dependency chains and cause odd compile issues as a result.
Basically, you have code in an "if" statement, and if you return early in that if statement, you might have code that you needed to run, but didnt.
Forcing devs to only "return once" encourages the dev to think through any stateful code that may be left in an intermediate state.
In practice, at my shop, we permit early returns for trivial things at the top of a function, otherwise only one return at the bottom. That seems to be the best of both worlds for this particular rule.
I think you're talking about this "goto fail" bug?
https://teamscale.com/blog/en/news/blog/gotofail
> In practice, at my shop, we permit early returns for trivial things
Are you also writing C or similar? If so, then this rule is relevant.
In modern languages, there are language constructs to aid the cleanup on exit, such as using(resource) {} or try {} finally {} It really does depend on if these conveniences are available or not.
For the rest of us, the opposite of "no early return" is to choose early return only sometime - in cases where results in better code, e.g. shorter, less indented and unlikely to cause issues due to failure to cleanup on exit. And avoid it where it might be problematic. In other words, to taste.
> Kent Beck, Martin Fowler, and co-authors have argued in their refactoring books that nested conditionals may be harder to understand than a certain type of flatter structure using multiple exits predicated by guard clauses. Their 2009 book flatly states that "one exit point is really not a useful rule. Clarity is the key principle: If the method is clearer with one exit point, use one exit point; otherwise don’t".
https://en.wikipedia.org/wiki/Structured_programming#Early_e...
this thinking is quite different to say, 25 years earlier than that, and IMHO the programming language constructs available play a big role.
Early return is perfectly manageable in C as long as you aren't paranoid about function inlining. You just have a wrapper that does unconditional setup, passes the acquired resources to a worker, and unconditionally cleans up. Then the worker can return whenever it likes, and you don't need any gotos either.
Right, so you allow early return only in functions that do not have any setup and clean-up - where it's safe. Something like "pure" functions. And you describe a way to extract such functions from others.
At this point what you need to do is stop treating compiler warnings as errors, and just have them fire the shock collar.
Negative reinforcement gets a bad rep, but it sure does work.
b) A return value that is explicitly marked like this is very different from an unused variable that gp suggested the cast to void idiom for. GCC does not warn on variables that are unused except for a cast to void.
> I work with a colleague that doesn't compile/run the code before putting up a MR.
Then erroring on unused variables will not help you anyway.
Anyway, all your issues sound like management problems. Not all projects are run that badly.
Which is annoying because the CI pipeline can take like 10 minutes to do the build and then you need to re-commit after turning the warnings on locally.
There are other issue like your code compiles differently in CI vs on your machine, which brings it own issues. Ignored warnings can cause other pieces to fail compilation or execution in other project/libraries. I had this happen in C# and VB.NET.
It is best just to turn on all warnings and errors and be done with it.
I've never heard particularly good reasons for not having it turned on all the time and that includes those mentioned in this thread.
> Then erroring on unused variables will not help you anyway.
The point I am trying to convey, which was a direct response to something the parent said:
"barbarians who commit code that complies with warnings"
IME it is very common for people to just straight up ignore warnings, and issues and sometimes they won't even check the thing compiles. I've worked as a contractor at a number of companies both large and small and this has been a constant.
> Anyway, all your issues sound like management problems. Not all projects are run that badly.
Again the point I was trying to convey is the expectations people have on here are far higher than what some of us have to deal with on a daily basis. So you have to put in loads of automated checks that I don't have to bother with when working with competent people.
The point being conveyed is your experience is not representative of what commonly occurs. I have worked as a contractor in a number of different orgs both small, large, private and public and more often than not unless you force people to fix these things, they won't.
> Find better managers.
How about you and others with similar attitudes realise that the world isn't perfect and sometimes you have to work with what you got.
Do you think I haven't been looking for a new position? Most of the jobs in my area are going to be more of the same.