From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 19 May 93 23:04:51 GMT From: sparky!sparky!dwb@uunet.uu.net (David Boyd) Subject: Re: McCabe package for Ada? Message-ID: <1993May19.230451.28559@sparky.imd.sterling.com> List-Id: In article <1te87gINNt5f@umbc7.umbc.edu>, berman@umbc.edu (Mike Berman) writes: |> The point of this post is to say that McCabe complexity analysis is |> useful, but should be supplemented by a suite of tools to look at code |> from other perspectives. The cyclomatic complexity measure, _by itself_, |> tells you nothing (as Wes pointed out), especially if a development |> community knows that it is the only metric being applied (then the above |> transformation is done solely for the purposes of reducing the complexity |> score). I have to agree with Mike here. No single metric can define complexity. You must look at a number of different factors/metrics and look for several bad cases together. For instance if I have a module with two consectutive case statements each with 10 seperate cases my cyclomatic complexity is going to be close to 100. However if I look at essential complexity it will be 1. In Mike's example, the problem would be indicated by high S0 and S1 metrics (program design complexity and program integration complexity). S1 is specifically the number of integration tests (or linearly independent subtrees) for the program. -- David W. Boyd UUCP: uunet!sparky!dwb Sterling Software IMD INTERNET: dwb@IMD.Sterling.COM 1404 Ft. Crook Rd. South Phone: (402) 291-8300 Bellevue, NE. 68005-2969 FAX: (402) 291-4362