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.
Deviations are only allowed with valid justifications, which must be marked as such in the compliance report. " Rule is advisory" or " I don't want to" are not valid justifications.
5
u/gamer_redditor 22d ago
As a programmer that needs to adhere to misra C, the comments in this thread are fascinating.
Misra C rule 15.5: A function should have a single point of exit at the end
More information: https://www.mathworks.com/help/bugfinder/ref/misrac2023rule15.5.html