MISRA C rules

[EVblog1]

Let me explain how I actually started C coding, because maybe that gives some context

I first installed GCC on my laptop and started writing C code in Notepad++. I used the command prompt to compile and run the programs. I also tried Code Blocks, but I personally preferred the first approach. Once I became comfortable with basic C programming, I thought I should try writing C for a microcontroller.

I bought some components like a P89V51RD2, crystal, resistors, capacitors and LEDs. Since the P89V51RD2 has an on-chip bootloader, I tried setting everything up on a breadboard and wrote some Embedded C code using Keil. I wanted to blink an LED, I used flash magic tool  but even after trying many times I couldn't get the MCU programmed properly.

After that I bought an 8051 development board. I started writing Embedded C programs using keil  for different peripherals such as LCD, buttons, UART, SPI, ADC, etc. Then I wanted more hands-on hardware experience, so I bought PIC microcontrollers and built things on a zero PCB. I used MPLAB and XC8 and experimented with different peripherals. After that I moved to ARM. I have an STM32 board with STM32CubeIDE.

The reason I'm explaining all this is that I have never really followed MISHRA C coding standard. My approach has mostly been: write the code, compile it, look at the warnings or errors, fix them, and keep doing that until the program builds successfully without errors or warnings.

So my actual question is about MISRA C. I'm still learning and mostly doing this as a hobby, so I may be missing something obvious here. I searched about this and found tools such as LDRA that can check whether a program follows MISRA C guidelines.

Do you guys normally follow only MISRA C rules when writing embedded C? If you do, how do you actually know that your code is compliant with the MISRA rules? Do you manually check the rules, or do you use some static-analysis tool?

[Siwastaja]

Read the actual rules and their reasoning, it gives the best understanding what it is all about.

Nearly no one would "normally" follow MISRA C in their own embedded projects "just for fun". The requirement comes from above. For some reason, MISRA C gets disproportionate emphasis; if you work in a regulated field, you will be having dozens of standards and requirements to follow, MISRA C being one, and maybe the simplest one of them to follow. It doesn't tell anything about how functionality and safety is proven or tested, i.e. the hard parts. It's not much more than a style guide. It makes more sense as a subset of some actual QC process.

Some of the rules are sane defaults and generally improve quality; some of the rules make generic, reusable, readable programming more difficult and as such increase the bug risk. It's not an automatic free lunch. It's somewhat opinionated, style guides always are.

Without proper quality control processes (in design and testing), it's utterly useless and offers no value in itself. Sorry. As such, it's a good litmus test of a kind: people who talk loudly about MISRA rules without much other context of other processes/standards, are posers.

[SiliconWizard]

Agreed. Note that MISRA-C is a "guideline", not a standard. In some standards related to safety-critical fields, MISRA-C is mentioned as recommended, but in practice, many companies in those fields do have their own set of rules and do not blindly follow MISRA-C (which has rules that all make sense in a certain context, but some are extremely restrictive). But they do have rigid development processes.

Now if you come from an "ad-hoc" development process (as you shortly described) to something more structured, MISRA-C will be the least of your concerns: you're coming from a further point and just applying some guidelines will not magically make your development process better.

Actually, and not to fire at them gratuitously, but ST's HAL code is IMHO a good example of what not to do. They have chosen to blindly comply with the entirety of MISRA-C (because it's a nice bullet point on presentations), but the resulting code is obnoxious to read, overly bloated and almost impossible to maintain (there's in particular a LOT of duplicated code in there that would certainly warrant being factored).

[Siwastaja]

almost impossible to maintain

And this is actually directly against the goal of making software less buggy, which MISRA authors and users probably share.

MISRA makes much more sense as a strict guide set for write-only autogenerated code, for example. Including humans doing the autogeneration part. I.e., formal specification with unambigious logical mapping -> safety-qualified monkeys write the code. This has decent track record in large companies doing products that rarely change. Add a wrong type of constraint ("hey, we made this business choice, do something quickly"), MCAS is the result. It is definitely MISRA-C and definitely doesn't crash from a dangling pointer.

For maintainable code, you want to use good abstractions and language features which reduce manual, error-prone work (copy-pasta for example), and MISRA C forbids useful constructs. For example, the maintainable codebases the whole world depend on use function pointers to provide configurable callback functions. The fact MISRA C forbids that and suggests an ad-hoc switch-case instead

But right design is everything, and processes for proof and testing come close. Everything else, including MISRA, is far behind in importance.

[nctnico]

almost impossible to maintain

And this is actually directly against the goal of making software less buggy, which MISRA authors and users probably share.

MISRA makes much more sense as a strict guide set for write-only autogenerated code, for example. Including humans doing the autogeneration part. I.e., formal specification with unambigious logical mapping -> safety-qualified monkeys write the code. This has decent track record in large companies doing products that rarely change. Add a wrong type of constraint ("hey, we made this business choice, do something quickly"), MCAS is the result. It is definitely MISRA-C and definitely doesn't crash from a dangling pointer.

For maintainable code, you want to use good abstractions and language features which reduce manual, error-prone work (copy-pasta for example), and MISRA C forbids useful constructs. For example, the maintainable codebases the whole world depend on use function pointers to provide configurable callback functions. The fact MISRA C forbids that and suggests an ad-hoc switch-case instead

IIRC the early MISRA rules did outlaw callback functions but later versions reverted that. Nowadays the rules are more sensible.

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.

[Siwastaja]

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.

Exactly; writing a flexible, generic abstraction layer over a large variety of products that are internally all over the place, while trying to minimize compromises and exposing most of the capabilities, is a noble goal, but also a very hard one, nearly impossible. It's clear they pulled the hard task off underresourced / poorly planned / poorly executed.

A simpler-to-use, easier-to-read version which locked out some features could have been better. After all, those who know exactly what they want and need to get all features / performance out of the devices won't be using the ST's HAL anyway, so all the crippled genericity goes to waste; catching 90% of use cases in a simple manner would have been better than aiming for 95%.

[hans]

Indeed, MISRA-C requirements are imposed by regulating bodies and the like.

Just like a company like Airbus will outsource the design and manufacturing of flight computers, but use different computer architectures and programming languages. The idea is that a common error will not propagate to all systems at once.
But no sane hobbyist would build their quadcopter with 1 ESC running STM32&Rust and another ESC running PIC32MX&C++.

Would a plane fly without this requirement? Absolutely.
Is this a guarantee that everything is designed correctly? Absolutely not.
But it definitely is a push into the right direction, if followed with a high amount of discipline.

If you want to work on the development process, I'd actually recommended looking into unit testing, Test Driven Development, etc. I only develop hardware-facing code on the bare metal. Many of my applications can run (partially) inside unit tests that can exercise common and the rarest of edge cases for every time I press compile&run. It also saves a lot of time not having to deal with embedded toolchains.
This technique is still not a guarantee things get better. That is all about understanding and well dosed application of the techniques.

[Siwastaja]

Indeed, MISRA-C requirements are imposed by regulating bodies and the like.

To be exact, I don't think so. Which makes the whole recurring cult-like MISRA discussion hilarious. As SiliconWizard said above, MISRA is not a standard. It's not any kind of legal entity at all. When I said the requirement comes from "above", I meant the head of engineering, in the company (or external customer); someone who designed the processes, and among other things, chose a style guide like MISRA "oh, this could be helpful". It will be documented as a part of the legal paperwork, but any other style guide, pre-existing or self-invented, would work similarly. MISRA is the least binding part.

[nctnico]

If you want to work on the development process, I'd actually recommended looking into unit testing, Test Driven Development, etc. I only develop hardware-facing code on the bare metal. Many of my applications can run (partially) inside unit tests that can exercise common and the rarest of edge cases for every time I press compile&run. It also saves a lot of time not having to deal with embedded toolchains.
This technique is still not a guarantee things get better. That is all about understanding and well dosed application of the techniques.

I think you'll like to use Claude code then. Claude can be made to unit test every module after a change has been made. It can be pretty thourough.

[Fire Doger]

If you want to work on the development process, I'd actually recommended looking into unit testing, Test Driven Development, etc. I only develop hardware-facing code on the bare metal. Many of my applications can run (partially) inside unit tests that can exercise common and the rarest of edge cases for every time I press compile&run. It also saves a lot of time not having to deal with embedded toolchains.
This technique is still not a guarantee things get better. That is all about understanding and well dosed application of the techniques.

I think you'll like to use Claude code then. Claude can be made to unit test every module after a change has been made. It can be pretty thourough.

It's amazing how easy is with Claude to get into unit testing.
Quotes for unit testing suites like Parasoft & Tessy cost tens of thousands per seat per year....

The generated tests are not perfect, but it does all the burden of configuring everything, you can refine test cases yourself at the end with minimal effort.

Instead of "misra C" we use "AI C", a bunch of rules on how to write comments on code so that agents have little to no room to hallucinate what's the purpose of each line, block of code, function, etc...

*PS. we don't do guided missiles nor F47, it's fine...

[Tation]

I cannot see any reason, apart of masochism, to follow MISRA for hobby projects.

In case you want to follow some guide, try the Barr C style guide. Short enough to be in-head, but with many basic, valuable rules that may help.

[Fire Doger]

I cannot see any reason, apart of masochism, to follow MISRA for hobby projects.

In case you want to follow some guide, try the Barr C style guide. Short enough to be in-head, but with many basic, valuable rules that may help.

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.

We have 3x 4k monitors and the standards require 80 characters line to be "printable"
If your code needs to be printed on a paper then you will probably know what you are doing and what standard to follow, there is no reason to follow blindly...

Focus on writing code that doesn't look like this:

Code: [Select]

if
 if
   if
     if
      if


[Doctorandus_P]

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

No. certainly not that many. I guess that 30% or so closer I really dislike using less then 3 characters for a variable. I use codeblocks and one of it's nice functions is that highlighting a variable is very quick by just double clicking it, and then it highlights all occurences of that variable. (Nearly any IDE has a similar function). And very often such variables are used in quite a lot of lines in (for example a 20 line) for loop. Highligting variables helsp a lot with analylzing code quicker (written by others, or your own code from a few years ago).

So I completely agree with 7.1.e

No variable name shall be shorter than 3 characters, including loop counters.

Source: https://barrgroup.com/sites/default/files/barr_c_coding_standard_2018.pdf

Overall, (for Evblog1). Just mentioning that you are interested in misra C is good. Not because it's a good standard (It was expensive at the time that I was interested in it myself), but because it shows you have an interest in writing quality code (Even for hobby stuff). And the intent of wanting to write good code is the important part here. Reading though a few coding standards, and understanding why they were written that way is a good way of becoming aware of "best practices". Reading code written by others is also very educational. Code written for "arduino" is very often atrocious. Every now and then you will find C source code that is written like poetry.

It's easy to write code that has no obvious errors. but it's much more difficult to write code that obviously has no errors.

[Siwastaja]

Focusing on some "variable length name rule" is the sin most style rules stumble on, and people start nitpicking and fighting over such rules. It's totally counterproductive. It's dopamine to our brain, perfect bikeshedding subject. It makes infinite discussion possible exactly because there is no right or wrong answer. The only correct realization is that the amount of discussion in itself indicates it doesn't matter the slightest. Completely irrelevant, just like tabs vs. spaces or brace style choices.

If a programmer gets confused from a short loop counter name, or if a programmer gets confused from a longer loop counter name, and if they can't participate in maintaining code written by others because the code uses a slightly differently named variable as a loop index, they need to be fired, not listened to.

It makes some sense to unify irrelevant style matters within a project or company. It's cosmetics. Similar to wearing a shirt with company logo. Doesn't affect engineering result, but fair enough, it's not a bad thing. Then you just follow the rules and don't complain. You are not some whistleblower just because you disagree with tabs vs. space. If the style guide has some real issue in it, which really affects code quality, talk about that. Like, maybe, if we had an imaginary style guide requiring to cast all pointers to (void *) and then back to the actual type, that would deserve backlash.

And on the flipside, if someone doesn't follow the style guide to the letter but produces otherwise good code, that's also not a reason to shit one's pants.

[Tation]

If some rule hurts you, but you are not enforced to follow it, as is the case in hobby projects, well, do not follow it. Not much problem for me to use idx or cnt, or row+col for loop counters, though. I still find many of the guidelines and rules in Barr to be common sensical and/or best practices (or, at least, good practices)

[udok]

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.

We have 3x 4k monitors and the standards require 80 characters line to be "printable"
If your code needs to be printed on a paper then you will probably know what you are doing and what standard to follow, there is no reason to follow blindly...

MISRA-C and similar rules are for large safety relevant projects.  The "if" path often has a test case which comes from a risk analysis. 
You do not want a simple "i" if dozens of developers look over the code and ask what this "i" stands for.
In the example the "len" is questionable too, better would be "InputSampleLength" or something more meaningful.

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.
Maybe my brain is not so fast and flexible anymore but i have learned that meaningfull variables are useful.
Except maybe for quick hacks with no more than 300 lines of code.

[Doctorandus_P]

Focusing on some "variable length name rule" is the sin most style rules stumble on, ...

Now you're grossly over reacting, and attempting to make others look bad by exaggerating some points into the absurd. Sure, it does not matter whether variable names are 3 or 5 characters, but having names that actually represent a meaning, and can also be searched for in the code is a significant advantage. And that does not work with single character variables. Just that it's so common to have this as a part of many style guides should be enough of an indication that it's an important issue. Wanting to fire people because they prefer sensible variable names is simply absurd.

For whitespace. I don't care much about whitespace. I pull any code through a beautifier that converts spaces to tabs and sets the brackets in a sensible place.

[eutectique]

I don't care much about whitespace. I pull any code through a beautifier that converts spaces to tabs [..]

Contradicting sentences.

[Siwastaja]

Now you're grossly over reacting, and attempting to make others look bad by exaggerating some points into the absurd. Sure, it does not matter whether variable names are 3 or 5 characters, but having names that actually represent a meaning, and can also be searched for in the code is a significant advantage.

It is, but there also is nothing wrong with this code:

Code: [Select]

for(int i=0; i<THE_PROPERLY_NAMED_ARR_LEN; i++)
    the_properly_named_arr[i] = THE_PROPER_INIT_VALUE;

There is no need to search this loop index over the project. It simply doesn't matter.

But that's the problem with hard rules - they are not always beneficial, but there is benefit in itself from having simple hard rules instead of long lists of exceptions. Nothing wrong in rules - I'm criticizing the amount of time spent discussing trivial and obvious things like this.

If company rule is hard rule, fine; install a lint tool which checks against it. Makes no sense to complain either way, you just live with that. But it also isn't the greatest thing since sliced bread.

[BBBbbb]

You will get more out of running general purpose linters and cranking up your compiler options than following MISRA rules (and running dedicated MISRA linter).

Most of the stuff in MISRA C is common sense, but nothing is absolute and some stuff from it shouldn't be practiced as religion. Common example are "magic numbers", yes they are bad if they are abstract values and should be behind a descriptive define, but other times "naked" numbers are a lot more readable and would expose an error easier than if obfuscated behind a define. MISRA linter would nag about having all of it behind defines.

Generally not bad to read MISRA rules and more importantly reasons behind them, and then use common sense about what you want to apply.

P.S.
Don't do TDD, unless refactoring old hard-to-understand code.

[EVblog1]

Thanks everyone for the replies. I think I have a better understanding now.

From what I understand, MISRA C is basically a set of C coding guidelines that companies can use for embedded software development. Following MISRA doesn't mean the software is automatically bug free or functionally correct. It is only one part of the overall development process

I also found out that the complete official MISRA C document is paid, and tools like PC-lint Plus and LDRA are commercial tools, although they offer trial versions.

https://www.mathworks.com/help/bugfinder/misra-c-2023-reference.html?utm_source

I think if we are working on a large project, we don't need to remember every MISRA rule and manually check every line of code. This is where static analysis tools are useful. They can automatically check many of the MISRA rules and report violations. Then the developer can fix the violations or, if there is a valid reason for not following a particular rule, document the deviation.

So my understanding now is that MISRA is not something you just memorize and apply line by line. It is part of a bigger development and quality process, and static analysis tools help with checking compliance.

Thanks again for the explanations.

[Siwastaja]

Thanks everyone for the replies. I think I have a better understanding now.

But I have two counter questions to you.

How many r's are in strawberry?

And if I want to get my car washed, and the car wash is 100 meters away, should I walk or drive there?

[EVblog1]

But I have two counter questions to you.

How many r's are in strawberry?

And if I want to get my car washed, and the car wash is 100 meters away, should I walk or drive there?

I think I found the answer I was looking for, so we can close the discussion for now. I'm not a professional embedded developer, I'm just trying to learn these things and understand how they are actually used in real projects, so that's why I asked the question.

Before asking anything else, I want to try a static analysis tool myself and see how it actually works. I think that will give me a better understanding than just reading about it.

So for now I don't have anything else to ask. Other members can focus on the other threads,

[NorthGuy]

Now you're grossly over reacting, and attempting to make others look bad by exaggerating some points into the absurd. Sure, it does not matter whether variable names are 3 or 5 characters, but having names that actually represent a meaning, and can also be searched for in the code is a significant advantage. And that does not work with single character variables. Just that it's so common to have this as a part of many style guides should be enough of an indication that it's an important issue. Wanting to fire people because they prefer sensible variable names is simply absurd.

The time you spend thinking about variable names and code formatting is the time you don't spend thinking about more important things. If someone spends most of his time thinking about these, it might not be a bad idea to fire him. Same as firing a secretary who only worries how she looks instead of doing her job.

Most variables will have very limited scope, so it is perfectly fine to use single letters for such variables.

[Siwastaja]

Most variables will have very limited scope, so it is perfectly fine to use single letters for such variables.

There is this old piece of wisdom that the variable name length should correlate with the size of the scope: very short names for small, local iterators spanning a few lines, long and descriptive for global variables spanning across modules - they must not only tell what they are, but also where they come from.

Such wisdom is plentiful in books and tutorials, but difficult to codify in hard rules. Hence, some rule-maker decided a compromise of three letter suffices. In reality, it forces writing longer names when it really doesn't matter, but still lets cryptic, too short abbreviations pass when it does matter.