Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!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: <2592@dataio.Data-IO.COM>
Date: 25 Jul 90 18:31:08 GMT
References: <3205@mica6.UUCP> <1050@ashton.UUCP> <142@srchtec.UUCP>
Organization: Data I/O Corporation; Redmond, WA
Lines: 22

In article <142@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes:
<In article <1050@ashton.UUCP> tomr@ashton.UUCP (Tom Rombouts) writes:
<<.......................... there is no real way to measure such things
<<as intelligence of the overall design and architecture, elegance of
<<algorithms, or quality of comments and documentation.  
<True.  But you CAN quantify (statistically, not deterministically) such
<things as "did the programmer, in general, decompose the design into
<subroutines (functions, procedures, ad infinitum) of manageable size?"
<A good policy (by my experience) is to take complexity metrics (and the like)
<with a grain of salt:  your metric rates some piece of code with a
<McCabe complexity of 22, and the average is 8.2.  So you check the code;
<there's no immediate reason for the excess complexity (based on your perusal).

In my experience, metrics are completely useless. There is no substitute for
an organized code review. This is where a listing is run of the entire
project code, and is passed around the other programmers who review it and
mark it up for style, clarity, obvious bugs, aesthetics, whatever.
Then you have a meeting where you go through all the markups.
You'd be amazed at the quality improvements that result. Another major
advantage of this is that the junior members of the team learn a lot from
the senior members, and the senior members learn new techniques from the
juniors. It's time well spent.