Determining C Complexity

[Walter Bright]

In article <7967 at jarthur.Claremont.EDU> ssdken at watson.Claremont.EDU (Ken Nelson) writes:
>In article <2592 at dataio.Data-IO.COM> bright at 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.