Frama-C-discuss mailing list archives

This page gathers the archives of the old Frama-C-discuss archives, that was hosted by Inria's gforge before its demise at the end of 2020. To search for mails newer than September 2020, please visit the page of the new mailing list on Renater.

[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