Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!athertn!hemlock!mcgregor From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Newsgroups: comp.software-eng Subject: Re: How do you measure code quality? Message-ID: <26703@athertn.Atherton.COM> Date: 6 Jul 90 17:40:22 GMT References: <3182@stl.stc.co.uk> <10865@netcom.UUCP> <11113@netcom.UUCP> <926@gistdev.gist.com> Sender: news@athertn.Atherton.COM Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor) Distribution: comp Organization: Atherton Technology -- Sunnyvale, CA Lines: 22 In article <3182@stl.stc.co.uk>, tom@stl.stc.co.uk (Tom Thomson) writes: > Just as the quote above is not claiming that not every program with a high > McCabe number is a bad one, I'm not claiming that every program with a low > McCabe number is a bad one either; just pointing that the McCabe number is > of very little use for anything. In one case that I am aware of a group decided to put a ceiling on McCabe complexity metric numbers for routines in their product. Any routine that was too complex was sent back for re-write. An unexpected side-effect was that the total number of files in the system grew as the McCabe numbers declined. And as the number of files grew, the complexity of the configuration grew, and there were more misconfigurations made in submittals to QA as a result. So while bugs in the modules were reduced, bugs in the configuration increased and required extra effort to fix. Again, this doesn't mean McCabe numbers are bad; I can imagine that if you put a ceiling on source statements you might have a similar effect. But I agree with other earlier posters that you need to be very careful what you measure and what interpretation you put on it. --Scott McGregor mcgregor@atherton