Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!njin!princeton!phoenix!egnilges
From: egnilges@phoenix.Princeton.EDU (Ed Nilges)
Newsgroups: comp.software-eng
Subject: Re: Counting semicolons (was: Re: WANTED: "C" code line counter program)
Message-ID: <8176@idunno.Princeton.EDU>
Date: 11 Apr 91 19:52:50 GMT
References: <1991Mar28.091725.17574@hollie.rdg.dec.com> <12644@pucc.Princeton.EDU> <1991Apr11.160835.15130@hollie.rdg.dec.com>
Sender: news@idunno.Princeton.EDU
Organization: Princeton University
Lines: 36

In article <1991Apr11.160835.15130@hollie.rdg.dec.com> jch@hollie.rdg.dec.com (John Haxby) writes:
>
>|> Run what through the C preprocessor first?  I don't think you'd
>|> want to run the measured code through the PP first because your
>|> engineers will deal with the unpreprocessed code in nearly all
>|> cases.
>
>You can't parse C without running the source through the PP
>first--what about people that define things like "BEGIN" and "END"
>to be "{" and "}" and other less obvius syntactic munging?
>

Although this is an excellent point, I don't think our metric should
concern itself with pathological uses of the C preprocessor such as
you describe, or it should give a "complexity" rating of "infinity"
to a program that uses the preprocessor to alter syntax.  There is
no need to replace, for example, left curly bracket by BEGIN and the
programmer doing it should be sent to Code Camp until he forgets he
ever knew Pascal :-).  The metric should determine if the preprocessor
is being used at the level you describe, and fail deliberately if it
is.

>
>
>You're right.  Actually, an ex-mathematician. C remains, however,
>difficult to do anything at all with because, as we both pointed out,
>it doesn't have obviously countable chunks.  Better designed or
>simpler languages have easy to recognize code `chunks'.

What languages?  Any block-structured language with a many-many
relationship between lines of code and statements is going to have
hard-to-count chunks.  FORTRAN and assembler will be "simpler"
but does this mean that they are better designed?

I maintain still you cannot "measure" complexity in any straightforward
sense acceptable to the beancounter mentality.