6 ms·

MISRA C is godawful, really bad. It is just a bunch of rules that "sound good" or are good in theory, but I doubt that they actually improve quality at all. I

MISRA C is godawful, really bad. It is just a bunch of rules that "sound good" or are good in theory, but I doubt that they actually improve quality at all. I once worked on a gigantic code base that religiously followed the "no early return" rule. Instead of just returning an error code, everything saved flags and used nested ifs galore. The code wound along the screen like a dying snake, horizontal scrolling everywhere even with a widescreen monitor. Refactoring was utterly impossible, fixing simple bugs took months. I am still baffled how all my colleagues just went along with it and never were like: Wait a second! This is awful!

actionfromafar 3y ago
That's the rule that stuck with me. Because I hate it.
ReactiveJelly 3y ago
Jeez. I proposed to adopt some of the Joint Strike Fighter Air Vehicle rules for C++ [1] at one job, and I went through them marking each as "already in practice", "needs debate" or "I'm vetoing it" And I vetoed early return with a link to the article on railroad error handling. I don't know how it looks in C, but in C++ and Rust early returns are so much better. [1] https://www.stroustrup.com/JSF-AV-rules.pdf https://www.stroustrup.com/JSF-AV-rules.pdf
- paxcoder 3y ago
  I deprecate early returns (at least for happy cases). What article are you referring to?
- duped 3y ago
  Every time I write an early return (which is every time) I think about my first college lab that had the rules "no global variables, one return statement per function" that if you violated you were failed for the lab. Luckily our TAs graded those and they cared about as much about those rules as everyone else. Today one is a principle at MS and the other at Google. Guess they knew how to code.
- acuozzo 3y ago
  No RAII means that allowing early returns in C can increase the likelihood of not performing cleanup along error paths. Consider writing a function called connect() which opens a socket and, if successful, calls setsockopt, bind, and friends. If e.g. bind fails and you choose to return early, then you also have to remember to close the opened socket. In my own code I prefer to use early returns for all situations except ones like the aforementioned. For those I use a forward goto to a label named "off_ramp" which does the necessary cleanup and returns an error code.
FirmwareBurner 3y ago
>I am still baffled how all my colleagues just went along with it and never were like: Wait a second! This is awful! They probably went along if MISRA compliance is pushed by a clueless manager who wants to impress a customer with "our 100% MISRA compliance" and who doesn't want to hear about your 'WHYs' to exceptions to the rules, then all you can do is blindly comply and suffer through while you look for another job. Ask me how I know.
- staunton 3y ago
  How do you know? (Some anecdotes please?)
- 0x000xca0xfe 3y ago
  Yeah, and this is exactly the problem with standards like MISRA C and the reason I will never work on projects like this ever again. When rules become more important than reality, everybody directly involved just stops caring. The early return rule is easy to check, but what about a "don't write code with a mental load so high that nobody will be able to understand it next year" rule? If the customer wanted actual quality, they would hire dedicated testers and/or write a really good testing harness.
  - FirmwareBurner 3y ago
    >Yeah, and this is exactly the problem with standards like MISRA C and the reason I will never work on projects like this ever again. I think it's unfair to point the problem as being with MISRA. MISRA doesn't force you to be 100% compliant with everything there, you're free to pick and choose what you think makes sense for your project and use case and to have your own exception. It's just a set of guidelines, that's it.. The real problem is people(mangers) who don't understand it and want 100% compliance at all cost just because it sounds good and they feel it covers their ass ("nobody ever got fired for being 100% MISRA compliant" /s), instead of investing dev brainstorming time in pruning the list and having a sane review and approval process for exceptions. It's a problem with moving from engineering mentality to bodyshop mentality.
jpfr 3y ago
The recent 2023 version of MISRA C costs just a few pound as PDF. So I got it from $WORK. I don't have a lot of experience with the previous versions. But the 2023 version reads quite okay. It is not possible to mandate "though shall write good code" because it is not at all clear what that means. Instead they needed to come up with rules that can be checked with automated tools. The rules are classified as mandatory, required or advisory. Only the mandatory rules cannot be overridden by explicit documentation. As an example, "The goto statement SHOULD not be used" is an advisory rule. Given the bad bad spaghetti code that beginner programmers produce with goto, this is quite reasonable. Even though some code is definitely better with goto. For example to jump to some cleanup before returning. Similarly, "A function SHOULD have a single point of exit at the end" is an advisory rule only. The rationale for the rule stated in the standard is the following (slightly rephrased): 1. A single point of exit for a function is required by the IEC 61508 and ISO 26262 standards as part of the requirements for a modular approach. 2. Early returns may lead to the unintentional omission of function termination code. 3. If a function has exit points interspersed with statements that produce persistent side effects, it is not easy to determine which side effects will occur when the function is executed. I'm also a big advocate for early return. But the points from the rationale are valid. And I don't have a good alternative rule that achieves the same goal and is checkable with automated tools...
- 0x000xca0xfe 3y ago
  That's the thing. The rationale sounds good. But where is the evidence? The code base followed all the rules, yet it was worse and had more bugs than any non-conformant code base I have ever seen. And teaching beginners to strictly follow rules instead of mercilessly rewriting and testing code until it is sufficiently clean and correct is the worst you can do, IMHO.
  - jpfr 3y ago
    Imagine how much worse the code would have been without all those rules. If people don’t have taste, no rules will get you to good code. Only a bit less worse / better predictable behavior.
- 3y ago
deleted 3y ago
[deleted]
bluGill 3y ago
No early return is critical to understanding and maintaining functions of more than 10,000 lines. (probably the limit is around 100 lines, but in my experience functions are either less than 100 lines, or more than 10,000 lines - you rarely see anything in the middle in the real world). I'm a firm believer in not writing long functions so I like early return, but having had to deal with 60,000 line functions early return makes it even harder to figure out how to get someplace or why you didn't.
zik 3y ago
I honestly think that MISRA ends up creating worse code that's less reliable because it forces programmers into contortions to get even simple stuff done. It's like programming with one hand tied behind your back - and a lot of it seems to be for no good reason. I'm thoroughly convinced that MISRA was invented by someone who hates programmers and just wants to see them suffer for no reason. Can't use size_t because it's a variable sized type? Yeah, that's not a win. Can't do early returns to keep code clean and clear? Now we have to do a heap of flags and nesting, resulting in less maintainable code. I'm so grateful to have my code improved this way. Even the experts say that "deviations" are sensible and necessary. So what that really means is you shouldn't ever fully comply with MISRA because it's against common sense. And what does that tell you about companies which require MISRA compliance?

actionfromafar 3y ago

That's the rule that stuck with me. Because I hate it.

ReactiveJelly 3y ago

Jeez. I proposed to adopt some of the Joint Strike Fighter Air Vehicle rules for C++ [1] at one job, and I went through them marking each as "already in practice", "needs debate" or "I'm vetoing it" And I vetoed early return with a link to the article on railroad error handling. I don't know how it looks in C, but in C++ and Rust early returns are so much better. [1] https://www.stroustrup.com/JSF-AV-rules.pdf https://www.stroustrup.com/JSF-AV-rules.pdf

paxcoder 3y ago
I deprecate early returns (at least for happy cases). What article are you referring to?
duped 3y ago
Every time I write an early return (which is every time) I think about my first college lab that had the rules "no global variables, one return statement per function" that if you violated you were failed for the lab. Luckily our TAs graded those and they cared about as much about those rules as everyone else. Today one is a principle at MS and the other at Google. Guess they knew how to code.
acuozzo 3y ago
No RAII means that allowing early returns in C can increase the likelihood of not performing cleanup along error paths. Consider writing a function called connect() which opens a socket and, if successful, calls setsockopt, bind, and friends. If e.g. bind fails and you choose to return early, then you also have to remember to close the opened socket. In my own code I prefer to use early returns for all situations except ones like the aforementioned. For those I use a forward goto to a label named "off_ramp" which does the necessary cleanup and returns an error code.

FirmwareBurner 3y ago

>I am still baffled how all my colleagues just went along with it and never were like: Wait a second! This is awful! They probably went along if MISRA compliance is pushed by a clueless manager who wants to impress a customer with "our 100% MISRA compliance" and who doesn't want to hear about your 'WHYs' to exceptions to the rules, then all you can do is blindly comply and suffer through while you look for another job. Ask me how I know.

staunton 3y ago
How do you know? (Some anecdotes please?)
0x000xca0xfe 3y ago
Yeah, and this is exactly the problem with standards like MISRA C and the reason I will never work on projects like this ever again. When rules become more important than reality, everybody directly involved just stops caring. The early return rule is easy to check, but what about a "don't write code with a mental load so high that nobody will be able to understand it next year" rule? If the customer wanted actual quality, they would hire dedicated testers and/or write a really good testing harness.
- FirmwareBurner 3y ago
  >Yeah, and this is exactly the problem with standards like MISRA C and the reason I will never work on projects like this ever again. I think it's unfair to point the problem as being with MISRA. MISRA doesn't force you to be 100% compliant with everything there, you're free to pick and choose what you think makes sense for your project and use case and to have your own exception. It's just a set of guidelines, that's it.. The real problem is people(mangers) who don't understand it and want 100% compliance at all cost just because it sounds good and they feel it covers their ass ("nobody ever got fired for being 100% MISRA compliant" /s), instead of investing dev brainstorming time in pruning the list and having a sane review and approval process for exceptions. It's a problem with moving from engineering mentality to bodyshop mentality.

jpfr 3y ago

The recent 2023 version of MISRA C costs just a few pound as PDF. So I got it from $WORK. I don't have a lot of experience with the previous versions. But the 2023 version reads quite okay. It is not possible to mandate "though shall write good code" because it is not at all clear what that means. Instead they needed to come up with rules that can be checked with automated tools. The rules are classified as mandatory, required or advisory. Only the mandatory rules cannot be overridden by explicit documentation. As an example, "The goto statement SHOULD not be used" is an advisory rule. Given the bad bad spaghetti code that beginner programmers produce with goto, this is quite reasonable. Even though some code is definitely better with goto. For example to jump to some cleanup before returning. Similarly, "A function SHOULD have a single point of exit at the end" is an advisory rule only. The rationale for the rule stated in the standard is the following (slightly rephrased): 1. A single point of exit for a function is required by the IEC 61508 and ISO 26262 standards as part of the requirements for a modular approach. 2. Early returns may lead to the unintentional omission of function termination code. 3. If a function has exit points interspersed with statements that produce persistent side effects, it is not easy to determine which side effects will occur when the function is executed. I'm also a big advocate for early return. But the points from the rationale are valid. And I don't have a good alternative rule that achieves the same goal and is checkable with automated tools...

0x000xca0xfe 3y ago
That's the thing. The rationale sounds good. But where is the evidence? The code base followed all the rules, yet it was worse and had more bugs than any non-conformant code base I have ever seen. And teaching beginners to strictly follow rules instead of mercilessly rewriting and testing code until it is sufficiently clean and correct is the worst you can do, IMHO.
- jpfr 3y ago
  Imagine how much worse the code would have been without all those rules. If people don’t have taste, no rules will get you to good code. Only a bit less worse / better predictable behavior.
3y ago

deleted 3y ago

[deleted]

bluGill 3y ago

No early return is critical to understanding and maintaining functions of more than 10,000 lines. (probably the limit is around 100 lines, but in my experience functions are either less than 100 lines, or more than 10,000 lines - you rarely see anything in the middle in the real world). I'm a firm believer in not writing long functions so I like early return, but having had to deal with 60,000 line functions early return makes it even harder to figure out how to get someplace or why you didn't.

zik 3y ago

I honestly think that MISRA ends up creating worse code that's less reliable because it forces programmers into contortions to get even simple stuff done. It's like programming with one hand tied behind your back - and a lot of it seems to be for no good reason. I'm thoroughly convinced that MISRA was invented by someone who hates programmers and just wants to see them suffer for no reason. Can't use size_t because it's a variable sized type? Yeah, that's not a win. Can't do early returns to keep code clean and clear? Now we have to do a heap of flags and nesting, resulting in less maintainable code. I'm so grateful to have my code improved this way. Even the experts say that "deviations" are sensible and necessary. So what that really means is you shouldn't ever fully comply with MISRA because it's against common sense. And what does that tell you about companies which require MISRA compliance?