3 ms·

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 imp

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.
- bluGill 3y ago
  100% is easy to measure and report on. As soon as you allow even one exception it is really hard to figure out if the exception is really needed, or it is just a bad programmer being lazy at the expense of quality. Management should not have to figure that question out.
  - FirmwareBurner 3y ago
    >it is really hard to figure out if the exception is really needed, or it is just a bad programmer being lazy at the expense of quality That's exactly why you have (in self respecting companies) a sane internal standard for exceptions with workshops and trainings, and experienced senior devs review the exception requests, precisely to make sure it's never a lazy dev or junior.
    - bluGill 3y ago
      I've worked with some really bad senior devs, and some great junior devs who couldn't do things right because of those senior devs
      - FirmwareBurner 3y ago
        In Embedded C?
        bluGill 3y ago
        Yes. Companies not known for software can be really bad as the bosses don't know how bad the senior staff is
        FirmwareBurner 3y ago
        Never seen such a case. Was it a body shop, semiconductor company, or someone like Google where they put JS devs in charge of writing C? I worked in an automotive and IOT and the difference between juniors and seniors there was like between us and John Carmack. As a former embedded C dev I really can't fathom being better than seniors in this gig who have been in the trenches since you can't self study the kind of stuff you encounter in production devices.
        bluGill 3y ago
        To be clear, most senior developers are much better than juniors. However there is a tiny minority that is not.
actionfromafar 3y ago
I guess the implied reason is something like "don't make functions which can accidentally leak resources". "It would probably help to ban early returns." NO. It won't help. At all.
rcxdude 3y ago
>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? Ah, you mean cyclomatic complexity! we have a tool that can check that. It definitely always means a function is too difficult to understand if the cyclomatic complexity is above some arbitrary value and would be safer it is was split up! No exceptions or nuance there!

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.

bluGill 3y ago
100% is easy to measure and report on. As soon as you allow even one exception it is really hard to figure out if the exception is really needed, or it is just a bad programmer being lazy at the expense of quality. Management should not have to figure that question out.
- FirmwareBurner 3y ago
  >it is really hard to figure out if the exception is really needed, or it is just a bad programmer being lazy at the expense of quality That's exactly why you have (in self respecting companies) a sane internal standard for exceptions with workshops and trainings, and experienced senior devs review the exception requests, precisely to make sure it's never a lazy dev or junior.
  - bluGill 3y ago
    I've worked with some really bad senior devs, and some great junior devs who couldn't do things right because of those senior devs
    - FirmwareBurner 3y ago
      In Embedded C?
      - bluGill 3y ago
        Yes. Companies not known for software can be really bad as the bosses don't know how bad the senior staff is
        FirmwareBurner 3y ago
        Never seen such a case. Was it a body shop, semiconductor company, or someone like Google where they put JS devs in charge of writing C? I worked in an automotive and IOT and the difference between juniors and seniors there was like between us and John Carmack. As a former embedded C dev I really can't fathom being better than seniors in this gig who have been in the trenches since you can't self study the kind of stuff you encounter in production devices.
        bluGill 3y ago
        To be clear, most senior developers are much better than juniors. However there is a tiny minority that is not.

actionfromafar 3y ago

I guess the implied reason is something like "don't make functions which can accidentally leak resources". "It would probably help to ban early returns." NO. It won't help. At all.

rcxdude 3y ago

>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? Ah, you mean cyclomatic complexity! we have a tool that can check that. It definitely always means a function is too difficult to understand if the cyclomatic complexity is above some arbitrary value and would be safer it is was split up! No exceptions or nuance there!