Path: utzoo!attcan!uunet!mcsun!ukc!stl!tom From: tom@stl.stc.co.uk (Tom Thomson) Newsgroups: comp.software-eng Subject: Re: How do you measure code quality? Message-ID: <3182@stl.stc.co.uk> Date: 4 Jul 90 17:53:42 GMT References: <10865@netcom.UUCP> <11113@netcom.UUCP> <926@gistdev.gist.com> Sender: news@stl.stc.co.uk Reply-To: "Tom Thomson" Distribution: comp Lines: 34 In article <926@gistdev.gist.com> flint@gistdev.gist.com (Flint Pellett) writes: >To answer your question on the McCabe complexity, ................. > >With some problems, you just aren't able to break the problem apart >enough of course, and you will have complexity. If you use the >complexity measure to conclude "this is bad code" then you've misused >the measure. (There may be a high correlation between complex code >and poor code, but one does not perfectly imply the other.) > Some published work indicates no correlation at all between McCabe complexity measure and rate of change of code after release; while there's a very strong correlation between rate of change after release and source code size. [Barbara Kitchenham published some stuff on this years ago, I can't remember the exact reference]. For an economic measure of quality, post-release rate-of-change is pretty good: change arises because there were bugs; debugging after release is expensive. [Obviously, for something that is going through a planned series of releases with planned facility enhancements, not all change is to do with bugs, but the change that is is bad news.] So code size is a better (very much better) measure of code quality than McCabe Complexity - - the smaller the source code to do a job, the better the quality. The McCabe measure tells us something about the control flow graph of the program: so it is completely useless for code not written in a control flow language (ML, pure Lisp, Prolog, ......); it favours (assigns lower complexity to) programs written in a style which use jump tables in data areas instead of case statements in code and compute program addresses by arithmetic instead of using labels or procedure names, so it's going to tell you that really awful programs are pretty good. 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.