Path: utzoo!mnetor!uunet!husc6!cmcl2!phri!dasys1!samperi
From: samperi@dasys1.UUCP (Dominick Samperi)
Newsgroups: comp.software-eng
Subject: Re: program complexity metrics
Message-ID: <2252@dasys1.UUCP>
Date: 17 Dec 87 12:49:01 GMT
References: <561@ndsuvax.UUCP> <3850002@wdl1.UUCP> <242@pedsga.UUCP>
Reply-To: samperi@dasys1.UUCP (Dominick Samperi)
Organization: Datamerica Systems, NYC
Lines: 17
Keywords: Program complexity, cyclomatic complexity
Summary: Cyclomatic Complexity

If McCabe's cyclomatic complexity metric is essentially equal to the number of
decisions in a program module (IF's, AND, OR, etc.) plus 1, I don't see the
advantage in giving it a graph-theoretic interpretation. It is not equal to
the number of paths through a module, and it seems to be little more than the
number of forkings in a control graph (plus one). True, it can be computed
by counting nodes, edges, and components, but it is much easier to simply
count the number of forks and add 1, or to dispense with the control graph
altogether and simply count IF's, AND's, NOT's, etc. In Shooman's Software
Engineering text 'phantom paths' are added to a graph in order to compute
its cylomatic complexity. I don't see the point here at all (and the formula
used in this text, V(G) = e - n + p, will not work for graphs with p > 1;
must use V(G) = e - n + 2p).

-- 
	Dominick Samperi, Manhattan College, New York, NY
		...!ihnp4!cmcl2!manhat!samperi
		...!ihnp4!cmcl2!phri!dasys1!samperi