MISRA C rules

[ejeffrey]

Barr C has some very stupid rules,
for(uint8_t i; i<len; i++) for example is banned

you need
for(uint8_t index; index<len; index++)

99.99 percent of developers use just "i" for simple counting.

I don't, and if I'm asked to code review I always advise eliminating single letter variables.

I use:

Code: [Select]

for (int ii; ii < len; ii++) {...}

My specific reason is that ii/jj/kk is much easier to search for.  That's helpful even when the body is only a few lines.  And of course, scoping your variable to the for loop is useful whenever possible.  Sometimes if you have a break statement you want to access the loop counter after the loop exits, and then it makes sense to lift the scope to the enclosing block.

It's not a big deal, and but the statement that 99.99% of C programmers do _anything_ is categorically wrong, and I don't think there is anything "stupid" about a style guide that prefers that.

Of course the key word is prefer.  Every style guide should include an exception process, at least for semantic rules (like loop counter scope).  But in a collaborative environment exceptions generally need to be for a more functional reason than "I don't like this rule".  On your personal project of course you can do whatever you want, there are no police.

[ejeffrey]

long and descriptive for global variables spanning across modules - they must not only tell what they are, but also where they come from.

The latter part of that is mostly a C specific piece of advice.  Every other language in common use uses namespaces for this purpose.  For non-C languages having the variable name encode where it came from is as obsolete as Hungarian notation.

Module level variables still need a descriptive name, of course.  But encoding the module/class/scope in the variable name is unnecessary.

[NorthGuy]

It's not a big deal, and but the statement that 99.99% of C programmers do _anything_ is categorically wrong, and I don't think there is anything "stupid" about a style guide that prefers that.

I don't think it matters what other programmers do. What would you rather do - a thing that is more appropriate for your program, or something else just because others do it?

Style guides are very clever thing - they allow big companies to make their coders deplorable and also lower the cost of their workforce by allowing them to hire cheaper coders. However, it is silly to think that style guides lead to better (in whatever sense) programming.

Anyway, it's all in the past. There's no need for massive "teams" of deplorable coders any more - AI can do the same, only better.

[SiliconWizard]

Where it comes to the ST HAL: the biggest problem is that they tried to make it too flexible and the hardware it tries to control is pretty crappy. A recipe for a disaster. But that is not because of MISRA. In general poorly maintainable code is due to lack of skills. A good programmer (software architect) can design (I specifically avoid the word 'write') software to adhere  to MISRA coding rules.

Of course it was written to address a large number of use cases all in one, and that's one reason it's seen as "bloated" in practice, but let me tell you that the crux of the matter with the source code itself is not that. That "do it all" is just a design decision, and makes many of the functions inefficient, but that part is related to performance, not style.

The real horror is the amount of code duplication. That's something you get to see only if you really need to follow specific HAL functions, for instance, not to use them but to try and figure out how to use a specific peripheral when the doc itself is a mess. That's when you realize how convoluted *and* duplicated code is. There's a lot that could have been factored, but yet they seem to prefer duplication.

While duplicating code per se is not a direct byproduct of following MISRA-C, it's not directly discouraged either, and the general rule of "making everything explicit" tends to cause that effect. Devs shy away from factoring into sub-functions because they've been told that it obscures functionality. That's an insane approach, but quite common among those who blindly follow MISRA-C as far as I've seen.

One rule that also makes code pretty convoluted is the "single exit point" one. It has been deprecated in recent versions of MISRA-C, but of course not forbidden, so older code base following MISRA-C  have tons of convoluted flow control to enforce the single exit point.

Of course you can still write maintainable and readable code following MISRA-C, without code duplication, but it's quite common that when people have to follow strict rules, which are already pretty constraining, they'll rarely want to go beyond that and will be happy when the code base just passes static analysis for those rules.

[Fire Doger]

That exactly the reason why blindly following standards (either published, or personal hard rules) is bad.
I agree that "len" is bad, but BARC accepts it 

You believe you are not in 99.99% but I believe that everyone has written a bubble short once in his career with i and j  and knows what they mean in a loop
Or 2D arrays with x, y
Or kinematics with x, y, z

Sometimes 1 letter variables are better, even for reviewer...
in [x, y] is easier to see what goes first and what goes second, in [x_point, y_point] you have like 250% overhead on actual information, and just train your eye to skip part of the variable name...
Although, this doesn't mean that you can make a rule or exception for it, if you have 3 different x points then ofc you need bigger names...

Standards are just a compromise to avoid abuse...

[cfbsoftware]

At the start of my programming time i used simple variables like i,j,k or x,y,z even for complicated code.
When i look today over my old code i have no clue what i was doing back then.

That depends on how far back the start of your programming time was? If you were writing FORTRAN code, variables that started with the letters I, J, K, L, M, N denoted that the variable was implicitly an integer and all others were reals. If you were writing the code onto punched cards it would not be surprising that you wanted to keep the names short. If neither was true you didn't have a clue back then what you were doing