Determining C Complexity

[John Baldwin]

In article <2611 at dataio.Data-IO.COM> bright at Data-IO.COM (Walter Bright) writes:
>
>The possibilities, of course, are endless. An analysis program simply
>cannot know what the design of the program is supposed to be.

True enough.  Let me stop the discussion long enough to make sure I understand
what your point really is, and see if you and others understand mine.

If you are saying "software metrics can never replace thoughtful code
inspection,"  then I must heartily agree with you, and the discussion can
go on to more fruitful things than this.

If you are saying "there are things which 'mechanical' metrics or analysis
cannot catch, therefore they are useless," then I must disagree.

Let me draw a (very poor) analogy:  my electric dishwasher at home does not
do a good job of removing cooked-on food from broiler pans and the like.
If I am dumb enough to put those straight into the dishwasher, it only makes
them more stubborn to remove.  So I accept the less-than-optimal limits of
my tool and only use it for the great volume of "not quite as dirty"
kitchenware, and continue to tackle the worst of the cleaning by hand.

I am proposing that software metrics are a tool to be used in a like manner.
A fellow writer (I have forgotten whom) posted a message to the effect
"...if you want to measure quality, then measure quality..."
                                                 ^^^^^^^
That is precisely the purpose of any *metric*, to objectively quantify the
aspects of the software development process which ARE Quantifiable (and which
we find profitable to do so).  [For example, I don't see how it might benefit
us to measure the number of times the word "the" occurs within a comment,
although it's certainly feasible to build a filter to look for that.]

Metrics (and analysis tools) will never replace thoughtful people.  They will
augment our capabilities by  (a) providing useful objective information in
numeric (measureable) form,  and (b) performing additional "drudgery level"\


>	{	for (i = 0; i <= max; i++)	/* ERROR! should be i < max */
numeric (measurable) form,  and (b) performing meticulous analysis at the
level where automation is feasible and people are likely to err.

Consider LINT as an example of type (b) above; properly set-up and used, it
is invaluable for assisting the developer in producing solid code.

can be invaluable for assisting a developer in producing solid code.


Hopefully, this will clear up some of this discussion.

Incidentally, as an aside, the current project I'm involved with under my
current employer is NOT using software-metrics per se.  We ARE using careful
walkthroughs and code examinations.... and I will be the first to object if
we decide to do away with this MOST USEFUL tool.
-- 
John T. Baldwin                      |  johnb at srchtec.uucp
Search Technology, Inc.              |  johnb%srchtec.uucp at mathcs.emory.edu
standard disclaimer:                 |  ...uunet!samsung!emory!stiatl!srchtec..
opinions and mistakes purely my own. |  ...mailrus!gatech!stiatl!srchtec...