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

[Steve Tockey]

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:

Code can be bad syntactically (structurally): long functions (I've seen
3400+ lines in a single function), high cyclomatic complexities (I've seen
2400+ in a single function), too many parameters on function calls (I've
seen over 40), etc. 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.

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.

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.
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.


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.



-- steve




-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Derek M Jones <derek at knosof.co.uk>
Organization: Knowledge Software, Ltd
Date: Tuesday, March 1, 2016 5:30 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"

Paul,

> Whilst it is true that quality or safety cannot be inspected into a
>product
> the Fagan Inspections can and do prevent bad code going further so
> long as the process can keep the bad code from passing by.

What is bad code and how does one detect its presence?

There are obvious errors, such as use of uninitialized variables.

There are suspicious constructs, that is use which experience
has shown to be unintended, such as assignment rather than equality
test in an if-statement (i.e., one = instead of two).

Suspiciousness is not a binary variable.  A cost/benefit decision
has to be made about how suspicious a usage has to be before it
is worth investing time looking at it (and estimates of suspicious
have large error margins associated with them).

-- 
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE