[SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

[paul_e.bennett at topmail.co.uk]

On 01/03/2016 at 5:02 PM, "Steve Tockey" <Steve.Tockey at construx.com> wrote:
>
>Derek M. Jones wrote:
>"What is bad code and how does one detect its presence?"
>
>The problem is that "bad code" is a multi-dimensional beast:

Yes. I'll reveal my answers based on my own coding standards.

>Code can be bad syntactically (structurally): long functions (I've 
>seen
>3400+ lines in a single function), 

The function is to large and needs to be refactored. It is likely that at
this size the interfaces are not that clear either. My own limit is that 
the function has to fit on one page of A4 paper with more than 50% 
as comment lines. Highest ratio I have had is a 20 line comment for 
a one line functional definition.

> high cyclomatic complexities 
>(I've seen
>2400+ in a single function), 

Way too high and definitely uninspectable and untestable. (no way 
could you guarantee 100% coverage by any measure with that high 
a complexity and there is not enough time in the universe to have 
covered it thoroughly enough). My own standard suggests that
refactoring should occur if the cyclomatic complexity raises above 
seven without a really good justification statement.

> too many parameters on function calls 
>(I've
>seen over 40), etc. 

Again, a sign that functions need refactoring. Try a limit of 6 
parameters without needing explicit justification.

> Much of this could be addressed by 
>establishing and
>enforcing a meaningful coding standard. Most, if not all, of this 
>is
>detectable using automated tools.

Try writing meaningful code comments and reviewing them to
ensure the intent matches the requirements. Then coding just 
from those reviewed (and approved) comments. Such practice 
provides good focus for the coder and done correctly leads to
lean and efficient coding of the application.

>Code can be bad semantically: the behavior of the code is 
>inconsistent
>with specification and/or user expectation. Call them "bugs" or 
>"defects",
>it's the same underlying issue. Testing can help detect some of 
>this, but
>not all. Some amount of inspection is probably also necessary.

Agreed.

>Code can be bad pragmatically: bad naming, worthless or misleading
>commenting, etc. This is only detectable by human review of design 
>and/or
>code.
>
>Code can be bad holistically: what I mean here is that the code 
>could be
>perfect in all other respects but is still a bad fit in its 
>environment.

Agreed.

>I'm trying to call out Nancy Leveson's idea that "safety is not a 
>property
>of the system alone, its a property of the system in its 
>environment" (or,
>however she says it). The code could otherwise be perfect, but 
>being a bad
>fit in its environment still makes it "bad code". This may be 
>addressable
>by the validation side of verification & validation.

About the only position from Nancy that I could agree with I think.

>
>My point is that it's not a simple thing to precisely define "bad 
>code",
>neither is it a simple thing to detect it or repair it.

They say if it was easy everyone would be doing it.

Regards

Paul E. Bennett IEng MIET
Systems Engineer

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************