[RealityVoid]

I fully agree with your analysis of MISRA C.

The issue I have with it is that some people seem to be refusing using their brain when following rules. For exampe, MISRA static checkers compain if you do:

  x = 250

So I've seen people do:

  #define TWO_HUNDRED_FIFTY 250
  x = TWO_HUNDRED_FIFTY

And it drives me insane that people see some rules but don't actually understand what they're for and just skirt around it in the stupidest way possible.

[burfog]

Well, it's a stupid rule. There are times when a plain old number is more maintainable. You don't have to name it, you don't have the extra line of code, you can immediately see what the number is, etc.

[RealityVoid]

I disagree. There are a few cases where a number is more expressive - I even think MISRA has exemptions for 1, 0 and FF.

But in most cases what I want is not the number, it's the _meaning_ of the number. Be it the Command ID, ram block Address or whatever it is. Generally, having code sprinkled with magic numbers is pretty shitty.

In my view:

  a = a<<18;
  a |= b<<8;
  a |= c;

is a kosher use of numbers. But

  case(ChoiceID):
    switch 1:
      /* Do somethin'*/
    break;
    switch 26:
      /* Do somethin' else*/
    break;
    default:
    break;

is not. Generally, numbers are ok as long as you express mathematical ideas nut not ok when you express logical ideas.

[burfog]

Heh, you disagree, then go on to agree. You even provide an example! Another good one is computing the Hamming weight, where the code is far more understandable if you have the numbers right there.

Even your "switch 26" isn't always bad. If the value only occurs in exactly that one place in your code, it's probably better to use a comment in plain English. A comment is more readable than DO_SOMETHIN_ELSE and, normally, would go right in the place where you actually use the value.