Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!hollie.rdg.dec.com!jch
From: jch@hollie.rdg.dec.com (John Haxby)
Newsgroups: comp.software-eng
Subject: Re: Counting semicolons (was: Re: WANTED: "C" code line counter program)
Message-ID: <1991Apr12.110138.12510@hollie.rdg.dec.com>
Date: 12 Apr 91 11:01:38 GMT
References: <1991Mar28.091725.17574@hollie.rdg.dec.com> <12644@pucc.Princeton.EDU> <1991Apr11.160835.15130@hollie.rdg.dec.com> <8176@idunno.Princeton.EDU>
Sender: news@hollie.rdg.dec.com (Mr News)
Reply-To: jch@hollie.rdg.dec.com (John Haxby)
Organization: Digital Equipment Corporation
Lines: 27


In article <8176@idunno.Princeton.EDU>, egnilges@phoenix.Princeton.EDU (Ed Nilges) writes:
|> >                                             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.

If you're treating code as a cost (I hope) then
the metric is probably not as simple as the number
of chunks.

I would hate to confuse simplicity with good design.
Good designs tend to be simple, but simple designs
aren't necessarily good.

I think chunk counting in CLU is fairly easy: once you
can decide on the chunks you are going to count.
-- 
John Haxby, Definitively Wrong.
Digital				<jch@wessex.rdg.dec.com>
Reading, England		<...!ukc!wessex!jch>