In article <1993Mar2.165913.182@gtewd.mtv.gsc.gte.com> hancockj@gtewd.mtv.gsc.gte.com (Jim Hancock) writes:
>Is there a recognized standard on counting SLOC (source lines of code) for
>C and C++?

In C, the #line directive "causes the implementation to behave as if the
following sequence of source lines begins with a source line that has a
line number as specified by the digit sequence [...]" (section 3.8.4,
page 94 lines 10 to 12, in the classic version of the ANSI C standard).
This prevents using a conforming C implementation to count actual lines.

The C++ situation might be friendlier.  Ellis & Stroustrop says only that
it sets the predefined macro __LINE__, for diagnostics and debugging.

>It seems that every C project at my company has their own version of a
>SLOC counter, and each does it in a slightly different way.

Ah, you mean that some count statements or other characteristics instead
of lines, and/or there are varying opinions on counting the contents of
standard headers, other headers, code skipped by #if, etc.  The C standard's
definition of __LINE__ is connected to the file that is being read, and is
a count of physical lines, except when altered by the #line directive.
However, the standard does not and cannot specify that managers or
accountants should be interested in those particular numbers.  Also, the
C standard does not specify a way to add up all of the line counts.  Sorry.
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?

In <comp.lang.c,comp.lang.c++,comp.std.c,comp.std.c++> hancockj@gtewd.mtv.gsc.gte.com (Jim Hancock) writes:
>
>Is there a recognized standard on counting SLOC (source lines of code) for
>C and C++?

No there isn't.  I simply count the number of source lines with either
a semi-colon or a left-brace.  This gives a reasonable estimate
because it covers both declarations and statements, but not comments
and blank lines.

Other people I have talked to agree that it is a reasonable
approximation of "size", but it says nothing about complexity.

I think the UNIX command is

 egrep -c '[;{]' *.C

but I may have got the details wrong here.


   -- Dag

In article <C3FKoy.C0F@megatest.com> djones@megatest.com (Dave Jones) writes:
>In <comp.lang.c,comp.lang.c++,comp.std.c,comp.std.c++) hancockj@gtewd.mtv.gsc.gte.com (Jim Hancock) writes:
>))
>))Is there a recognized standard on counting SLOC (source lines of code) for
>))C and C++?
>
>... and if there were, what would it be good for?

Although we all know that SLOC is a poor measure of time/effort to
produce a software product, it is still used amoung the larger
government contractors as an estimator tool when developing a
software proposal.

Huge databases of previous project metrics are used to estimate the
time and effort necessary to produce a new product.

SLOC counters on their own are meaningless, but over time,
statistically,
the data does have some use...

Shawn

In article <C3FKoy.C0F@megatest.com> djones@megatest.com (Dave Jones) writes:
>In <comp.lang.c,comp.lang.c++,comp.std.c,comp.std.c++) hancockj@gtewd.mtv.gsc.gte.com (Jim Hancock) writes:
>))Is there a recognized standard on counting SLOC (source lines of code) for
>))C and C++?
>
>... and if there were, what would it be good for?

*Please!*  Let's not get into a discussion about the *usefullness* of
counting lines of code.  Especially in a thread crossposted to several
newsgroups where such an issue (the usefullness, that is) doesn't
belong.

Mr. Hancock merely asked if there were a "recognized standard" for such
an activity.  He did *not* ask for a dicussion on the merits of the
activity.  There's no benefit to posting such a reponse to his request.

-hans
--
  Hans-Gabriel Ridder <ridder@rust.zso.dec.com>
  DECwest Engineering, Bellevue, Washington, USA
  "I'd rather be writing MACRO-20!"
  Any opinions expressed are not those of my employer, honest.