> 2. No magic numbers. > > Another person complains about not being able to do magic numbers. While it can get tedious, you really shouldn't. They use the most

> 2. No magic numbers. > > Another person complains about not being able to do magic numbers. While it can get tedious, you really shouldn't. They use the most insane example of #define ONE 1. BUT, even in this case you can argue that if the requirements were changed for a base 8 or other numbers system, you could easily port the app by just changing these define macro's rather than scouring through the code. It's not that tedious, and it can make the codebase more flexible and solve issues and porting. I agree with you on magic numbers in general, but there have to be practical limits. I was paid to deliver tight production code that was performant, often interfacing with assembly because that was what we had to do with the cheap micro our project used. I wasn't worried about other number systems, it wasn't worth spending R&D $$$ to make the code compatible with other number systems. I'm not writing code that will last 100 years. I deliver to schedules and budgets. Your arguments strike me as a bit too rigid, too academic. Not practical in the real world. In my mind if (condition) num_found = num_found + 1 is clearly superior than this MISRA version if (condition) num_found = num_found + ONE Because the first case is the simplest implementation, incredibly explicit as it. We're counting something. That's abundantly clear. The second case is inferior because, as a reviewer doing their job, I have to go and lookup what ONE actually is. In case someone defined it weird. I start thinking "Maybe it's not 1, maybe it's 1.0". or "maybe its fixed point like (1.0 * 256)." The moment I'm wondering what ONE is actually defined as, I'm no longer thinking about the code I'm reviewing. I have to interrupt my mental process to go find ONE, understand that, and then come back and pick up with what I was reviewing. This stuff matters. Clarity matters. When 1 might not be 1, well then I have to think harder. Compounded, all these little complications dilutes the quality of the code overall. And programmer resources and time are limited. Also, not to nitpick but your example "goto cleanup" is also not MISRA compliant. I'd argue that use of gotos is a greater sin than returning early. I'm pragmatic. I've used gotos, where it makes sense, which is almost never. But never say never. Gotos are nearly always bad. Early returns are useful sometimes. Assembly should be avoided when possible. Code is a tradeoff. When writing interrupt service routines, performance matters, and I found this is where I broke the MISRA rules the most. Because the code had to be tight. That was the value my company brought to the customer. We could get out of the interrupt quick enough to guarantee deadlines in the rest of the code. You do this by letting yourself write complex code in some places, the places that matter. And you scrutinize those more than you do the rest of the code. MISRA (as misapplied by mid level managers) pretends the above statement doesn't matter.