Newsgroups: comp.software-eng
Path: utzoo!utgpu!cunews!bnrgate!scrumpy!toby!larryd
From: larryd@toby.bnr.ca (Larry Dunkelman)
Subject: Re: WANTED: "C" code line counter program
Message-ID: <1991Mar27.030018.25807@scrumpy@.bnr.ca>
Sender: news@scrumpy@.bnr.ca (USENET (SY))
Organization: Bell Northern Research Montreal, Canada.
References: <12609@pucc.Princeton.EDU# <350@tslwat.UUCP> <12632@pucc.Princeton.EDU>
Date: Wed, 27 Mar 91 03:00:18 GMT

Once a metric is published, programmers can easily find ways (if they want
to) to fool the system.  If management wants to measure bugs/lines of code,
then programmers could just write lengthy programs.  If management wants
to measure productivity as lines of code/man month, then again, programmers
could "pad" their programs.

In my experience this does not happen.  We have been using a simple "C" code
line counter which does exactly that -- counts lines of code (not statements).
A source line is either blank, a comment or a line of code.  That's it.
If a programmer splits an assignment statement over three source lines, then
it will be counted as three lines of code.  If he writes 5 statements on the
same line, then they will be counted as one line of code.

In practice this works fine since *most* programmers are reasonable about
how they "format" their code.  

Our counter has an option to ignore lines with just a "{" or "}", but in
the final analysis, even that option doesn't make much difference.

Maybe a way to rid ourselves of the degenerate cases being discussed lately
is to run the programs through pretty printers before counting.  

I am not a great defender of Lines of Code (or Kilo Lines Of Code - KLOC)
as a good metric.  There are cases where a designer has had a negative
productivity since he managed to reduce the size of the program and add
functionality at the same time.  BUT, until someone comes up with a better
metric, LOCs are what management will ask for.

Larry
larryd!bnrmtl@larry.mcrcim.mcgill.edu