Validation of MISRA?

[MMouse]

Hi MM!

> Code bloat: Space in source code is free.

I don't agree. Only so many lines will fit on a video screen at a time. A piece of code which you have to scroll up and down to understand or debug is more difficult (hence more liable to bugs) than a concise equivalent. Mentally filtering out clutter whilse reading code is hard work.

I agree BUT the same is true of compact code that is complex. Taken to either extream it is not good. However there is a tendancy to be "too clever" when trying to save space on screen. The result is less readable code and more errors.

Besides these days with 19 in LCD screens being the norm from 14 inch (real view 12") CRT screens 135 columns is more common than 40 or 80 colums. Though with graphic secreens this is no longer the measurement it once was.

I read somewhere (it may have been in Steve McConnell's book about coding) that bug frequency / 1000 lines of code is pretty much independent of the source language. It therefore seems plausible that code written in "MISRA-C" will contain more bugs than the same stuff written in full C. This is the sort of issue that the putative studies should address.

Bugs per line of code is a good measure. However you have to measure like for like. Some projects have a much lower B/KLOC than others. One would expect MISRA-C compliant code to have a low B/KLOC

> I would expect that within a few weeks the MISRA team will produce a paper or something to show that MISRA C does save time/money/errors etc since you have raised a the spectre of the Emperors New Clothes! They have to show that the emperor IS wearing new cloths and it is not just a con. Especially as they are now starting MISRA-C 3

Good! That is what I want.

You and me both :-)

>On the other side what evidence do you have that MISRA-C DOES bloat code and DOES cost (overall) for training etc

I think both are self evident. Note that I used the word "somewhat" when I mentioned bloat. Examples are rule 14.8 (The statement part of "if" etc., may only be a compound statement) and rule 14.7 (Only one "return" in a function). So that perfectly idiomatic C like

if (foo > MAX_FOO)
return EXCESSIVE_FOO;


gets bloated to

int ret_value;
....
if (foo > MAX_FOO)
{
ret_value = EXCESSIVE_FOO;
}
else
{

} /* or some other similar coding strategem */
return ret_value;

However, I don't think it would be productive to get into an argument about detailed coding practices in this thread. But I would like some evidence that the bit of bloat caused by these rules actually brings more benefit than cost.

I take your point that the source code get bigger on the page. However it is also more readable and in some cases easier to debug. I will see If I can find the example I did years ago where more compact code was less easy to debug in an emulator.

As for the training, I've had to learn how to use my firm's chosen tools for detecting and "fixing" the things it points out. That's time I would rather have spent debugging.
Alan Mackenzie (Nuremberg, Germany)

Now this I must take issue with. A good static analyser will, after you have set it up and spent time being trained on it, catch a hell of a lot of bugs. The poit is it is far more cost effective to find bugs with a static analyser just after they have been writen than woorking out what just happened in a test/debug session.

There are several reports on the telecoms industry that show that good use of static analysis will reduce the bug hunting phase deastically and give more time for additional testing. So you get a better tested product in a shorter space of time because more of the problems were picked up durring coding and the bug hunting time was much shorter.

Happy new year.

Chris