Determining C Complexity

[Ken Nelson]

In article <2592 at dataio.Data-IO.COM> bright at Data-IO.COM (Walter Bright) writes:
>....[excerpted]...
> 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.  If you use high complexity or some other
   metric to help you decide what to review, and how in-depth to review,
   you can prevent or detect a lot more bugs.

   I am interested in how you (or anybody who cares to
   comment) organize code reviews.  Do you have a checklist,
   is there a packet of information that is prepared before
   the review?  How is it prepared or collected?  What people
   are invited.  Too often I have worked on projects where the 
   "organization" for the review meant merely rounding up the
   people. Once organized,
   if not controlled they would degenerate into religous 
   debates between factions of different programming styles.

   Are there any articles or books you could recommend that
   detail a "good" review process?

   I have seen these items used in past reviews:

     1. A static analyzer's output including full cross reference.
     2. A list of know bugs, and or needed improvements.
     3. A list of To Be Determined items about the code.
     4. A pretty printed output.
     5. LINT output, if written in C.
     6. The set of requirements for the program or program
 	section.
     7. Coding standards for the project.


   Any additions, subtractions, comments??


			
				Ken Nelson
				Principal Engineer
				Software Systems Design
				3627 Padua Av.
				Claremont, CA 91711
				(714) 624-3402