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

From: Steve Tockey < >
Date: Tue, 1 Mar 2016 15:44:14 +0000

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.

-----Original Message-----
From: systemsafety <systemsafety-bounces_at_xxxxxx on behalf of Derek M Jones <derek_at_xxxxxx Organization: Knowledge Software, Ltd
Date: Tuesday, March 1, 2016 5:30 AM
To: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx 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_xxxxxx

_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Tue Mar 01 2016 - 16:44:25 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:08 CEST