Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!mailrus!ncar!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.software-eng
Subject: Re: C source lines in file
Summary: not uncommon...but still wrong!
Keywords: C
Message-ID: <16019@vail.ICO.ISC.COM>
Date: 17 Aug 89 22:39:35 GMT
References: <35120@ccicpg.UUCP> <10707@smoke.BRL.MIL> <257@opel.UUCP>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 27

johnk@opel.UUCP (John Kennedy) writes:
> It is not uncommon to generate NCSL (Non-Commentary Source Lines) for
> purposes of productivity.

I assume this intended "productivity measurement".  And sure, it's not
uncommon...but it's still wrong.  A count of non-commentary source lines
says nothing about the amount of actual code produced, nor about
productivity.  In fact, it's worse than that:  If you tell people their
productivity will be judged (in part) on NCSL, their coding style will
change--probably for the worse.  An experienced eye can often tell whether
code was written with an eye to NCSL as a productivity measure!

> ...NCSL estimates have a relationship to
> size and execution time predictions...

They have some relationship to code size--not very good, but possibly
slightly useful if you compensate for density of code (number of tokens
per line). They have little or no relationship to execution time predic-
tions; in too many cases the relationship will be inverted.

Consider replacing an algorithm which is O(n^2) in time with a more
complicated O(n*log(n)) algorithm.  Or consider manual inline expansion
of time-critical code sequences instead of using a procedure.  Both
increase the program text size in order to decrease execution time.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Are you making this up as you go along?