19-12-2007, 01:38 PM
Hi MM!
>Training:- New programmers need training anyway. A good coding standard stops bad habits and promotes a much better Engineering understanding of the language.
Agreed. Which is why it's important to ensure that MISRA is, in fact, a _good_ standard, for some value of \"good\". I'm asking in this post for some, any, evidence of this goodness.
> Far too many have bad habits that look \"cool!\" which store up trouble later on. So Training on MISRA is not a cost as it saves time later. I can give anecdotal evidence for this.
As can I. But many (most?) of these aren't covered by MISRA; Overlong names, deeply nested structs, typedeffing lots of different sorts of integer.... I think that no matter how comprehensive you make coding standards, somebody will find a way to write grotty code whilst conforming to them. MISRA, in this respect, looks reasonable, up to a point.
> 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 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.
[ .... ]
> 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.
>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.
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.
>Best wishes for the Season
And yourself, sir!
>MMouse
--
Alan Mackenzie (Nuremberg, Germany)
>Training:- New programmers need training anyway. A good coding standard stops bad habits and promotes a much better Engineering understanding of the language.
Agreed. Which is why it's important to ensure that MISRA is, in fact, a _good_ standard, for some value of \"good\". I'm asking in this post for some, any, evidence of this goodness.
> Far too many have bad habits that look \"cool!\" which store up trouble later on. So Training on MISRA is not a cost as it saves time later. I can give anecdotal evidence for this.
As can I. But many (most?) of these aren't covered by MISRA; Overlong names, deeply nested structs, typedeffing lots of different sorts of integer.... I think that no matter how comprehensive you make coding standards, somebody will find a way to write grotty code whilst conforming to them. MISRA, in this respect, looks reasonable, up to a point.
> 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 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.
[ .... ]
> 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.
>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.
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.
>Best wishes for the Season
And yourself, sir!
>MMouse
--
Alan Mackenzie (Nuremberg, Germany)