←back to thread

327 points AareyBaba | 1 comments | | HN request time: 0.191s | source
Show context
time4tea ◴[] No.46184345[source]
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!

replies(11): >>46184442 #>>46184460 #>>46184571 #>>46185232 #>>46185373 #>>46186276 #>>46186377 #>>46186457 #>>46186510 #>>46186705 #>>46189488 #
tialaramex ◴[] No.46185373[source]
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.

replies(3): >>46185961 #>>46186729 #>>46190376 #
platinumrad ◴[] No.46186729[source]
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".
replies(2): >>46188461 #>>46190952 #
bboygravity ◴[] No.46188461[source]
Why is "no early returns" not a good rule?

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.

replies(6): >>46188976 #>>46189208 #>>46189367 #>>46189520 #>>46189549 #>>46193709 #
1. jandrewrogers ◴[] No.46189208[source]
Early returns makes the code more linear, reduces conditional/indent depth, and in some cases makes the code faster. In short, it often makes code simpler. The “no early returns” is a soft version of “no gotos”. There are cases where it is not possible to produce good code while following those heuristics. A software engineer should strive to produce the best possible code, not rigidly follow heuristics even when they don’t make sense.

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.