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: <2600@dataio.Data-IO.COM>
Date: 30 Jul 90 18:39:41 GMT
References: <2592@dataio.Data-IO.COM> <157@srchtec.UUCP> <7967@jarthur.Claremont.EDU>
Distribution: na
Organization: Data I/O Corporation; Redmond, WA
Lines: 44

In article <7967@jarthur.Claremont.EDU> ssdken@watson.Claremont.EDU (Ken Nelson) writes:
>In article <2592@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
<< There is no substitute for an organized code review.
<   Right.  Metrics don't replace reviews, they augment them. 
<   Where they really help is when time and resources are limiting
<   what you can review.

I'm arguing against using metrics at all. If you're limited in resource,
decide to review the newest code, or the most critical.

<   Do you have a checklist,
<   is there a packet of information that is prepared before
<   the review?  How is it prepared or collected?  

A listing is run of all the code. Each reviewer gets a pen of a different
color, and they simply read the code and mark it up.
Some things they look for:
	o Obvious bugs
	o Worthless comments:	i++;	/* increment i */
	o Failing to check for error returns from functions
	o Failing to check malloc returns for NULL
	o Meaningless comments
	o Array fencepost problems
	o Possible array overflows
	o Portability problems
	o Inefficient code	(i & 1) ? 1 : 0
	o Dead code
	o Violations of group style consensus
	o Things that should be typedef'd, things that should not be typedef'd
	o Global functions and variables that should be static
	o Modularity
	o Anything else that the reviewer thinks should be discussed or
	  revised

<   What people are invited.

The team programmers, plus 'guest' programmers from other projects.
Managers are excluded.

<   Once organized, if not controlled they would degenerate into religous 
<   debates between factions of different programming styles.

The moderator's job is to prevent such degenerations and to keep
things constructive.