Re: Lines-Of-Code Utility?

Re: Lines-Of-Code Utility?

[joecool]

Well.... there are different standards for calculating lines of code in
source files.  Particularly with C code.

Many projects, in attempting to track software development costs and
determine areas where the software development process can be improved,
collect what are called software metrics.   I'm not trying to insult
anyone's intelligence.  I know many, if not most, of the readers of this
newsgroup are aware of what software metrics are.  I simply provided this
brief & simple description for those who MAY not know what they are so
please do not be offended. :-)

I need a lines-of-code utility that will run on NT and produce reports on
lines-of-code for Ada 95.  It would be nice if it can run recursively on a
specified directory  structure.

If there are various standards for reporting lines of code for Ada 95, I
would like to know them.  I am looking for any information anyone can
provide on such utilities.

Thanks

Brian Orpin wrote in message <3642c88c.24407137@news.geccs.gecm.com>...
>On Tue, 27 Oct 1998 17:29:05 -0600, "joecool" <nobody@nowhere.com> wrote:
>
>>Does anyone know if there is a utility that will run on NT 4.0 that can be
>>run in batch mode to generate a report on the lines of code contained in
Ada
>>source files located within a directory tree
>
>Depends on your definition of lines of code <VBG>.
>

Re: Lines-Of-Code Utility?

[dennison]

In article <B7TGnHsB#GA.174@samson.airnet.net>,
  "joecool" <nobody@nowhere.com> wrote:
> Well.... there are different standards for calculating lines of code in
> source files.  Particularly with C code.
>
> Many projects, in attempting to track software development costs and
> determine areas where the software development process can be improved,
> collect what are called software metrics.   I'm not trying to insult
> anyone's intelligence.  I know many, if not most, of the readers of this
> newsgroup are aware of what software metrics are.  I simply provided this
> brief & simple description for those who MAY not know what they are so
> please do not be offended. :-)
>
> I need a lines-of-code utility that will run on NT and produce reports on
> lines-of-code for Ada 95.  It would be nice if it can run recursively on a
> specified directory  structure.
>
> If there are various standards for reporting lines of code for Ada 95, I
> would like to know them.  I am looking for any information anyone can
> provide on such utilities.

Well, "grep" exists for NT (available from the cygwin32 area of www.cygnus.com
). grep -c ";" has always been sufficient for me.


--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Lines-Of-Code Utility?

[dewarr]

In article <B7TGnHsB#GA.174@samson.airnet.net>,
  "joecool" <nobody@nowhere.com> wrote:
> Well.... there are different standards for calculating lines of code in
> source files.  Particularly with C code.
>
> Many projects, in attempting to track software development costs and
> determine areas where the software development process can be improved,
> collect what are called software metrics.   I'm not trying to insult
> anyone's intelligence.  I know many, if not most, of the readers of this
> newsgroup are aware of what software metrics are.  I simply provided this
> brief & simple description for those who MAY not know what they are so
> please do not be offended. :-)
>
> I need a lines-of-code utility that will run on NT and produce reports on
> lines-of-code for Ada 95.  It would be nice if it can run recursively on a
> specified directory  structure.
>
> If there are various standards for reporting lines of code for Ada 95, I
> would like to know them.  I am looking for any information anyone can
> provide on such utilities.


Lines of code is always a dubious metric, since it is so variable.
Some people count semicolons, but that can be quite misleading.
For example, in the GNAT sources, we use a LISPy style for tree
construction that often results in very long statements. Here is
an example of one to give an idea of the style:

         Assign :=
           Make_Block_Statement (Loc,
             Declarations => New_List (
              Make_Object_Declaration (Loc,
                Defining_Identifier => Rnn (J),
                Object_Definition =>
                  New_Occurrence_Of (R_Index_Type (J), Loc),
                Expression =>
                  Make_Attribute_Reference (Loc,
                    Prefix => New_Occurrence_Of (R_Index_Type (J), Loc),
                    Attribute_Name => F_Or_L))),

           Handled_Statement_Sequence =>
             Make_Handled_Sequence_Of_Statements (Loc,
               Statements => New_List (
                 Make_Loop_Statement (Loc,
                   Iteration_Scheme =>
                     Make_Iteration_Scheme (Loc,
                       Loop_Parameter_Specification =>
                         Make_Loop_Parameter_Specification (Loc,
                           Defining_Identifier => Lnn (J),
                           Reverse_Present => Rev,
                           Discrete_Subtype_Definition =>
                             New_Reference_To (L_Index_Type (J), Loc))),

                   Statements => New_List (
                     Assign,

                     Make_Assignment_Statement (Loc,
                       Name => New_Occurrence_Of (Rnn (J), Loc),
                       Expression =>
                         Make_Attribute_Reference (Loc,
                           Prefix =>
                             New_Occurrence_Of (R_Index_Type (J), Loc),
                           Attribute_Name => S_Or_P,
                           Expressions => New_List (
                             New_Occurrence_Of (Rnn (J), Loc)))))))));

Now often conventional wisdom would say that long statements are
a bad thing, but in this case, once you know the format of the
tree that is being constructed (the tags before => correspond to
the tree selectors), then this functional style is FAR clearer
than some sequence of assignments to temporary variables (which
we used to do in days long gone past).

Obviously counting semicolons is a ludicrous measure here.

One other commonly used metric is non-blank non-comment lines.
That's what we use in the GNAT project when we want to gather
this kind of information.

Of course both these measures correspond to programs so trivial
that it is easier to write them than to download them :-)

Actually I think a better metric would be to count tokens, and
then divide by some agreed on typical-tokens-per-statement value
to get the more familiar lines of code metric, but I don't know
of any tool that does that, or what the typical value should be.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Lines-Of-Code Utility?

[Tucker Taft]

joecool (nobody@nowhere.com) wrote:

: Does anyone know if there is a utility that will run on NT 4.0 that can be
: run in batch mode to generate a report on the lines of code contained in Ada
: source files located within a directory tree (that is, it needs to
: recursively look for Ada source within a dir tree)?  And if so, what is it
: capable of doing?

See below for an (n)awk script we use.

It counts totally blank lines, lines that consist of only a comment,
and all other lines.  This corresponds with our definition of 
line-of-code, which is non-comment, non-blank lines.

If you prefer a count of lines with semicolons, this counts
those as well, though because things like "if/elsif" and "case" 
only add one semicolon no matter how long they are, our
experience is that semicolon counts are not as useful as lines
of non-comment, non-blank code for sizing development effort.

Of course comments involve some typing effort, but they generally
pay back in ease of debugging and understanding, so a comment
line if anything has a negative correlation with development time.
Similarly, well-placed blank lines can also speed development.

And the usual disclaimer applies that lines-of-code is not
a great indicator of development effort, though it is
generally better than nothing!

: Thanks.

: George

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company
-----------------------------------------------
#!/bin/nawk  -f

BEGIN		{
			tcmnt = 0; tsloc = 0; tblnk = 0; tmloc = 0; files = 0;
		}

function show(fil,cmnt,sloc,blnk,mloc) { 
	  printf("\nComment lines: %5d\n", cmnt);
	  printf("Blank lines:   %5d\n", blnk);
	  printf("Ada lines:     %5d\n", sloc);
	  printf("-----------------------\n");
	  printf("Total lines:   %5d ", cmnt+sloc+blnk);
	  printf(fil, files);
	  printf("\n");
	  printf("      semis:   %5d ", mloc);
	  printf("\n");
	  files++;
	}

FNR == 1	{	if (fil != "") show(fil,cmnt,sloc,blnk,mloc);
			fil=FILENAME;
			tcmnt += cmnt; tsloc += sloc; tblnk += blnk; 
			tmloc += mloc;
			cmnt = 0; sloc = 0; blnk = 0; mloc = 0;
		}

/;/		{ mloc++; }
/^[ \t]*--/	{ cmnt++; next; }
/^[ \t\r]*$/	{ blnk++; next; }
/^*$/		{ sloc++; next; }

END		{ 
			show(fil,cmnt,sloc,blnk,mloc);
			tcmnt += cmnt; tsloc += sloc; tblnk += blnk;
			tmloc += mloc;
			if (files > 1) 
			    show("Total for %d files",tcmnt,tsloc,tblnk,tmloc);
		}

Re: Lines-Of-Code Utility?

[Martin C. Carlisle]

In article <B7TGnHsB#GA.174@samson.airnet.net> you write:
>I need a lines-of-code utility that will run on NT and produce reports on
>lines-of-code for Ada 95.  It would be nice if it can run recursively on a
>specified directory  structure.

I put a very simple line counter at 
ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/count.exe

It only does one file at a time.

--Martin

-- 
Martin C. Carlisle, Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standard or 
policy of the US Air Force Academy or the United States Government.

Re: Lines-Of-Code Utility?

[Marc A. Criley]

dewarr@my-dejanews.com wrote:
> 
> In article <B7TGnHsB#GA.174@samson.airnet.net>,
>   "joecool" <nobody@nowhere.com> wrote:
      <snips>
> >
> > I need a lines-of-code utility that will run on NT and produce reports on
> > lines-of-code for Ada 95.  It would be nice if it can run recursively on a
> > specified directory  structure.
> >
> > If there are various standards for reporting lines of code for Ada 95, I
> > would like to know them.  I am looking for any information anyone can
> > provide on such utilities.
> 
> Lines of code is always a dubious metric, since it is so variable.

     <more snips>

Capers Jones, software metrics guru, had the following to say about
counting source lines in the October 98 issue of Crosstask
  (http://www.stsc.hill.af.mil/CrossTalk/1998/oct/letters.html):

"Elizabeth Starrett's article, "Measurement 101," Crosstalk, August 1998,
was interesting and well written, but it left out a critical point.
Metrics based on "source lines of code" move backward when comparing
software applications written in different programming languages. The
version in the low-level language will look better than the version in
the high-level language. 

"In an article aimed at metrics novices, it is very important to point
out some of the known hazards of software metrics. The fact that lines
of code can't be used to measure economic productivity is definitely a
known hazard that should be stressed. 

"In a comparative study of 10 versions of the same period using 10
different programming languages (Ada 83, Ada95, C, C++, Objective C,
PL/I, Assembler, CHILL, Pascal, and Smalltalk), the lines of code
metric failed to show either the highest productivity or best quality.
Overall, the lowest cost and fewest defects were found in Smalltalk and
Ada95, but the lines of code metric favored assembler. Function points
correctly identified Smalltalk and Ada95 as being superior, but lines
of code failed to do this."

Therefore one might consider the "lines-of-code utility" to be low :-)

(The following is directed towards the bean-counters, not the metricians.)
So why is SLOC still the most common basis for productivity measurements?
Because it's the easiest thing to measure.  The results are inaccurate,
and can easily mislead, but it's easy and cheap.  Function points or
other metrics that depend on the content of the software require more
work to extract.  And while they may be more accurate, and provide more
insight into development and productivity, resulting in more accurate
budgeting, scheduling, and more efficient application of resources to
reduce life cycle costs, well... it's easier to count semi-colons.

-- 
Marc A. Criley
Chief Software Architect
Lockheed Martin ATWCS
marc.a.criley@lmco.com
Phone: (610) 354-7861
Fax  : (610) 354-7308

Re: Lines-Of-Code Utility?

[Stephen Leake]

"joecool" <nobody@nowhere.com> writes:

> Does anyone know if there is a utility that will run on NT 4.0 that can be
> run in batch mode to generate a report on the lines of code contained in Ada
> source files located within a directory tree (that is, it needs to
> recursively look for Ada source within a dir tree)?  And if so, what is it
> capable of doing?

I wrote a wrapper for an old "count of Ada statements" program from
the PAL; it counts all lines, terminal semicolons, and comment lines
in files listed on the command line. Using the cygwin tools 'find' and
'xargs', you can count lines in directory trees:

bash$ find . -name "*.ad?" -print | xargs ada_stats
File name	Statements, Lines, Comments
./Ada_Stats/ada_stats.adb	 47, 102, 29
./Ada_Stats/character_set.adb	 152, 264, 0
./Ada_Stats/character_set.ads	 22, 58, 30
./Ada_Stats/count_of_ada_statements.adb	 72, 225, 100
./hexdump/Source/hexdump.adb	 78, 140, 9
./command_line_io.adb	 38, 110, 8
./command_line_io.ads	 11, 74, 39
./time_convert.adb	 207, 463, 20

Total files      :  8
Total statements :  627
Total lines      :  1436
Total comments   :  235

Guess I need to allow more space for the file names :).

It does enough parsing to not count semicolons in strings and
comments. You might be able to enhance it enough to count tokens, as
Robert Dewar suggests.

Source is too long to post here, but I'd be happy to email on request
(I _really_ need to get web page at work!).

-- Stephe