Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rutgers!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!udel!princeton!pucc!EGNILGES
From: EGNILGES@pucc.Princeton.EDU (Ed Nilges)
Newsgroups: comp.software-eng
Subject: Re: WANTED: "C" code line counter program
Message-ID: <12583@pucc.Princeton.EDU>
Date: 13 Mar 91 16:57:18 GMT
References: <2969@inews.intel.com> <1991Mar12.163607.18799@axion.bt.co.uk>
Reply-To: EGNILGES@pucc.Princeton.EDU
Organization: Princeton University, NJ
Lines: 55
Disclaimer: Author bears full responsibility for contents of this article

In article <1991Mar12.163607.18799@axion.bt.co.uk>, pyoung@axion.bt.co.uk (Pete Young) writes:
>
>Counting statements is a possible answer to the second question. So,
>has the first question been satisfactorily answered? In many cases, I
>suspect not. But counting lines of code is a lot easier than thinking
>about useful measures of the size and complexity of a program.

I'd like to make a philosophical point.  Since it questions the
foundations of software engineering, busy managers and engineers
may wish to skip this post, or save it for later perusal.

Much of software engineering seems to be a doomed attempt to
measure complexity.  I pointed out in a previous post that if
you count lines of code in a C program you may be misapplying a
model valid in the one-statement-per-line FORTRAN world but invalid
in the world of C, since C statements may be many per line, may be
spread over many lines, and may even contain other statements.

So the best metric is to count statements, and given a good yacc
description of C and a lexical analyser such a tool is
easy to develop.

But even if you have measured statements, have you measured
complexity?  A program written in simple French (using French
rather than English identifiers) is "too complex to maintain"
when given to an American programmer since there is a 99.99%
probability that such a programmer has never learned French.
Complexity is a PSYCHOLOGICAL property.

I suggest that complexity PRECEDES measurement.

Instead of measuring complexity and appealing to your programmers
to reduce the complexity of their code, I respectfully submit
that software engineers concentrate on providing the environment
wherein the programmers can write CORRECT code...at whatever
level of complexity is appropriate.  If this means that software
engineers spend their time designing good PHYSICAL environments
for programmers, determining the best location of vending machines
and making certain that programmers have privacy and interaction
when necessary, then such activity would be more productive than
what goes under the rubric of software engineering.

Although there certainly is a lot of crud code out there, much of
it is not "overly complex".  A lot of it is overly simple, not
capturing the problem requirements.  And a lot of it is wrong.

Telling a programmer who has written a correct program that is
complicated according to your metric is peculiarly offensive.  It
reminds me of the critics in the movie Amadeus, who tell the
young Mozart that his music has "too many notes."  Not all program-
mers are Mozarts, but let's not go in the opposite direction,
which I believe abuses a valuable economic resource (the nation's
programming workforce) by being concerned that its members jump
over artificial and ill-considered hoops represented by software
metrics.