Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!samsung!emory!stiatl!srchtec!johnb
From: johnb@srchtec.UUCP (John Baldwin)
Newsgroups: comp.lang.c
Subject: Re: Determining C Complexity
Keywords: C, complexity, metrics, cyclomatic complexity, McCabe
Message-ID: <161@srchtec.UUCP>
Date: 1 Aug 90 22:03:47 GMT
References: <157@srchtec.UUCP> <7967@jarthur.Claremont.EDU> <2600@dataio.Data-IO.COM>
Distribution: na
Organization: search technology, inc.
Lines: 28

In article <2600@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
|
|I'm arguing against using metrics at all. If you're limited in resource,
|decide to review the newest code, or the most critical.
|
   [excerpted]
|Some things they look for:
   [more deleted]
|	o Array fencepost problems
|	o Possible array overflows
|	o Portability problems
|	o Inefficient code	(i & 1) ? 1 : 0
|	o Dead code

All of the above are good candidates for automation: they can be detected
just as easily using "mechanical" methods.  Supplying the review group with
the output from a code analyser will provide MORE TIME for the people to do
what humans do better at anyway, namely, exercise judgement.  It is exactly
this aspect which makes code reviews so valuable (in both your opinion and
mine).  A properly-written automated tool will be much better at catching
dead code and the like than a human reader will; filter programs don't get
tired, distracted, or bleary-eyed.

-- 
John T. Baldwin                      |  johnb@srchtec.uucp
Search Technology, Inc.              |  johnb%srchtec.uucp@mathcs.emory.edu
standard disclaimer:                 |  ...uunet!samsung!emory!stiatl!srchtec..
opinions and mistakes purely my own. |  ...mailrus!gatech!stiatl!srchtec...