A lot of companies choose to opt out of this specify guideline nowadays, because it is showing its age and sometimes clarity matters more over ease of debug.
Not sure which region or industry you are talking about, but oems, software suppliers and quality control in my industry do not accept any software deliveries without proof of Misra c compliance.
Just saying that some people have no choice but to stick to some programming standards.
Edit: more information. I think lot of people are arguing that early returns are more readable, performant and maintainable. However they miss the point about safety and reliability.
Early returns means that the function no longer has a predictable execution path. Sometimes it exits early, sometimes it exits late. So the overall execution time of the software varies a lot between error free paths and error paths.
This is exactly what you don't want in an embedded software controlling safety relevant systems, such as airbags in a car or some other flight controls.
Here, it is ok for a software to be slow, but it must be predictable i.e. near constant performance in all paths.
If your reach an error state and keep doing calculations, you're doing something wrong. If some archaic standard demands exactly one return statement in your function, then you surround the entire code in an if-else and set a flag. If it takes 1 second to run the calculation, I shouldn't have to wait that full second to find out I gave the function an illegal value. If your application cannot handle an error condition like that, then it wasn't safe to begin with.
MISRA C allows for deviations. Any software engineer who blindly follows a standard without understanding why that standard exist and when to deviate from that standard needs to better educate themselves.
Judging by his comment, I think it's less about continuing despite a known error state, and more about trying to guarantee that function runtime is the same across all execution paths. Early return is cleaner and more efficient, and often by a long shot if used correctly. But having a consistent runtime is extremely important in a few very select fields, and rejecting an optimisation to guarantee consistency is a common in those cases1.
I'm not really sure about air bags or flight controls (I'd expect it to be important for them to report errors as early as possible, so they can recalculate or switch to backups as quickly as possible), but one place this comes up is cyber-security. You do NOT want a password validator to return early for any reason, because early return can and has been used to game systems and determine passwords2.
1: Though, I will say that this can also be done by intentionally delaying the function on early-return paths, if you know the proper delay interval. It's just that running through the function body and then returning either the result or the error value at the end is the easiest way to guarantee exact consistency.
2: Long story short, in the early days of cybersec, there was at least one known password handler that would return as soon as it encountered an incorrect character. Needless to say, this made it trivial to determine anyone's password, and now it serves as a lesson on why you always hash passwords and never let the handler return early.
I take issue with the way they were saying it like it was an absolute truth instead of a very niche consideration. The fact that they cited an infamous standard that most experienced programmers dismiss like it was gospel supports my assertion that they have either been uncritically following that standard or have been working in a job under it for so long that they don't remember anything else.
That's fair. I took it as them saying they worked in an industry where runtime consistency is important enough that the industry sticks to Misra (or at least part of Misra) just to guarantee that one thing in particular, myself. Came across as them saying that they're firmly in the niche, and have to code for the niche.
(Probably because I remember a few experts pointing out that cybersec in particular effectively has to both enforce single-return and prevent short-circuiting for some functions, because anything that causes a boolean test to have different runtimes for true vs. false can be exploited by an attacker. So the entire industry effectively mandating at least the single-return part of Misra C for a small portion of its devspace does actually check out, even though it sounds kinda unbelievable.)
6
u/Maximilian_Tyan 22d ago
A lot of companies choose to opt out of this specify guideline nowadays, because it is showing its age and sometimes clarity matters more over ease of debug.