NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/software/4437

Internet Message Format | 1992-11-20 | 1.7 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sdd.hp.com!swrinde!elroy.jpl.nasa.gov!ames!agate!doc.ic.ac.uk!uknet!root44!hrc63!mrcu!uk.co.gec-mrc!paj
From: [e-mail]-mrc (Paul Johnson)
Newsgroups: comp.software-eng
Subject: Complexity metrics: Beyond McCabe.
Message-ID: <2235@snap>
Date: 20 Nov 92 09:46:37 GMT
Sender: [e-mail]-mrc
Reply-To: [e-mail]-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, Essex
Lines: 27

I've been having a look at complexity metrics.  McCabe "A Complexity
Measure" (IEEE Trans SE, SE2 1976) sounds like a good start.  He
measured complexity by counting flow control paths within a program.
Has anyone extended this work?  Is it seen as a significant kind of
metric?

I have had a look at function points.  The trouble is that they behave
like fractals: the closer you look the more you see.  This strikes me
as useless.

What makes a piece of code hard to understand and follow?  McCabe
concentrated on flow control because the debate of those days was
structured vs. unstructured programming, and he sought to show that
structured programs were simpler.  Today we have a debate on OO vs
non-OO.  Can we find a metric which measures what we intuitively call
"complexity" in a program?  (I think not, although we may be able to
approximate it).  Is it possible to show that an OO design can reduce
the complexity of a program?

Should a metric like this take numbers of variables into account?
Assignment statements?  If I take a chunk of code and put it into a
function, inserting a function call in its place, have I increased
complexity, decreased it or not affected it?

Any and all comments will be read with interest.

Paul.