--- layout: fc_discuss_archives title: Message 40 from Frama-C-discuss on May 2012 ---
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frama-c-discuss] -metrics discrepency Boron/Nitrogen



On Tue, 15 May 2012, Richard Bonichon wrote:

>    There are multiple questions in your e-mail. I'll answer by the following
>    points:
> 
>    * To the first question, the answer is yes and no. Some metrics on the
>    normalized AST could depend on the version of Frama-C (for example the
>    number of gotos). But cyclomatic complexity should not.
>    * What you (seem to) want (ie metrics on the source AST) exists, it is
>    described in
>    the metrics plug-in's manual (for Nitrogen).** Do not hesitate to read it
>    (feedback is appreciated).

I have not yet read it - but I will do that as the next wstep, I posted the 
results because they seemed "obvioulsly" wrong to me...:)

>    * The target complexity on the normalized AST is cyclomatic complexity ---
>    the various informations displayed are mostly used to compute cyclomatic
>    complexity.
>    * Cyclomatic complexity is not computed on the source AST. It could be but
>    it is
>    not. It is usually easier to do analyses on the normalized AST but the
>    more fundamental
>    reason is stated below.**
>    * Cyclomatic complexity is (or at least should be) the same between the
>    normalized and the source AST. In your example, it is indeed the case as
>    the or-condition creates a decision point. That is , there are 3 if
>    statements + one || expression = 4 decision points in the source AST and 4
>    if statements in the normalized AST. The cyclomatic complexities are thus
>    equal in this case, as they should be.
>

for cyclomatic complexity that is ok , but for general code-monitoring its a bit of a problem as there are coding standards that don't like goto statements  :(
 
>    Just out of curiosity, what are the metrics you are interested in ?
>

well the first is cyclomatic complexity as it is (I hope) a good indication of 
how hard it wiould be to achieve a MC/DC of the code, which some standards mandate. But more generally I'm interested in any automated procedures that allow to "trigger" on unresonable "complexity explosions" in code that users "fix". And finally I would like to use such metrics to look at how generated code compares to hand-written code.

But as you can see from my inprecise answer I've just started with this stuff - and as I knwe frama-c a bit form other projects it was the first one I played with.

thx - and furtehr questions after I read the manual...
hofrat