comp.lang.ada
 help / color / mirror / Atom feed
From: dewarr@my-dejanews.com
Subject: Re: Lines-Of-Code Utility?
Date: 1998/11/04
Date: 1998-11-04T00:00:00+00:00	[thread overview]
Message-ID: <71prhl$uod$1@nnrp1.dejanews.com> (raw)
In-Reply-To: B7TGnHsB#GA.174@samson.airnet.net

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    




  reply	other threads:[~1998-11-04  0:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Auij4FgA#GA.64@samson.airnet.net>
     [not found] ` <3642c88c.24407137@news.geccs.gecm.com>
1998-11-02  0:00   ` Lines-Of-Code Utility? joecool
1998-11-04  0:00     ` dewarr [this message]
1998-11-05  0:00       ` Marc A. Criley
1998-11-04  0:00     ` dennison
1998-11-05  0:00     ` Martin C. Carlisle
1998-11-04  0:00 ` Tucker Taft
1998-11-05  0:00 ` Stephen Leake
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox