Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: Determining C Complexity
Keywords: C, complexity, metrics, cyclomatic complexity, McCabe
Message-ID: <2606@dataio.Data-IO.COM>
Date: 2 Aug 90 00:33:30 GMT
References: <7967@jarthur.Claremont.EDU> <2600@dataio.Data-IO.COM> <204@ssg0.UUCP>
Distribution: na
Organization: Data I/O Corporation; Redmond, WA
Lines: 16

In article <204@ssg0.UUCP> petej@ssg0.UUCP (Peter M. Jansson) writes:
<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.
<By the way, how does one define "most critical?"

I'd define most critical as code that is the most difficult to find problems
in. Examples are interrupt handlers. Interrupt handlers can easily have bugs
in them that only show up once every 1000 times they are called, and thus
are very difficult to verify correct by running test cases. The best
way to test and debug interrupt handlers is by "gedanken experiments",
that is, carefully examining the code with your brain.

A least critical piece would be, say, the code that parses the command
line switches. Bugs there usually show up without too much prodding and
are easily tested and fixed.