Path: utzoo!attcan!uunet!jarthur!watson!ssdken From: ssdken@watson.Claremont.EDU (Ken Nelson) Newsgroups: comp.lang.c Subject: Re: Determining C Complexity Keywords: C, complexity, metrics, cyclomatic complexity, McCabe Message-ID: <7967@jarthur.Claremont.EDU> Date: 27 Jul 90 20:02:15 GMT References: <1050@ashton.UUCP> <142@srchtec.UUCP> <2592@dataio.Data-IO.COM> <157@srchtec.UUCP> Sender: news@jarthur.Claremont.EDU Reply-To: ssdken@watson.Claremont.EDU (Ken Nelson) Distribution: na Lines: 52 In article <2592@dataio.Data-IO.COM> bright@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