(a = 0), (b = 1), (c = 2);
What about that ?
Three lines. My rule would be to break down each statement into its
grammatical components and if a (comma,separated) expression or
expression-list is found - then count each of its components
individually as one line of code (and to repeat this process
recursively) - otherwise if the statement can be broken down without
finding either an expression or expression-list - then the statement
counts as one line of code.(or something like that, USENET doesn't pay
well enough for me to work all of these details out
)
For example, the statement above expression matches this grammatical
production in the C++ grammar:
expression-statement => expression ';'
since we have to break down the expression before we can count the
lines, we do so:
expression => expression ',' primary-expression
and so forth. Essentially we wind up with with three of these
'(' assignment-expression ')'
which - when broken all the way down contain neither an expression nor
expression list - so the final tally is three lines of code - one for
each non-expression component of the expression production..
a = f( x=1, b=3 );
... and that.
Three lines. Again we start with an expression-statement:
expression-statement => assignment-expression ';'
becomes
assignment-expression => identifier '=' postfix-expression
becomes
postfix-expression => identifier '(' expression-list ')'
Since we found an expression-list we can no longer count this
statement as one line of code. Instead have to break down the
expression-list and count its components:
expression-list => assignment-expression ',' assignment-expression
So these two assignment-expressions here and the expression-statement
we started with - gives us three lines of code altogether.
Construct::Construct()
: a(1),
b(2),
c(a+b)
{
}
Three (two literals and one additive-expression)
... oooh that too.
enum { a = 1, b = 2 };
and that !
No lines of code assessed for an enum definition..
int func( int a = 1, int b = 2, int * c = new int[3] );
No lines of code awarded to a function declaration. There is after all
no reason to penalize a program for merely declaring a routine. On the
other hand, implementing a function and calling a function do
contribute to a program's line count. The idea here is to encourage
calls to external, library routines (whose lines are not included in
the program's line count) and otherwise to discourage redundant
implementations and to promote code reuse.
Note also that the use of default arguments is encouraged here, since
default arguments often reduce the number of arguments that need to be
provided at the call site (and with each argument counting as one line
of code - the savings could be significant).
... and this
if ((flags & FNM_PERIOD) && *n == '.' &&
(n == string || ((flags & FNM_FILE_NAME) && n[-1] == '/')))
return FNM_NOMATCH;
Three lines. One line of code for the if-statement, one line for the
logical-and expression in its condition, and one line of code for the
return statement. Note that the complexity of the expression does not
necessarily means that we have undercounted the "lines" of code here.
Presumably the variables appearing in the condition-expression had to
be declared somewhere - and each of those declarations would count as
one line of code (by my measure). The strategy here is to assess a
cost for declaring a variable - but not to penalize the program for
using the variable. Therefore removing unused variables is an easy and
effective way to reduce the number of lines of code assessed to a
program.
After all, the entire motivation for counting lines of code in a
program is to build awareness that code added to a program also adds
to its cost, code once-written is not "free" - its mere presence in a
program's sources represents a cost. Therefore any line of code in a
program that does not have to be there - is just money being wasted.
... or this
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0, NULL
);
I count 10: one for the postfix-expression FormatMessage, one for each
of its arguments argument - except for the postfix-expression
MAKELANGID (which is probably a macro - but I'll pretend is a
function) is assessed two lines additional lines (one for each of its
arguments).
+ a bazillion other constructs.
Yes. And in real life I would not expect the C++ programmer to count
the lines of code in a program by hand, as I did above (it's a little
tedious actually). Instead I would imagine that a C++ compiler would
be better suited to do the line counting - leaving the programmer free
to focus on constructive ways to bring the number of lines counted -
down.
Greg
