lines of code?

[Digital Puer]

I have two questions about the metric of 'lines of code':


1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.


2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?


Thanks for any info.

 

[Andrew Thompson]

I have two questions about the metric of 'lines of code': ....
2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

If you could reduce a 100,000 line program to 5,000
lines without losing clarity in the code or introducing bugs..

_That_ shows proficiency.. ;-)

 

[nos]

we would always use NCSL
"non commentary source lines"
for our "C" programs
a physical line could contain
1. source code only
2. comment only
3. some of each
we would add up from 1 and 3
however, there is some fudge, for example with eclipse I have
in a current java program the following
------
out.println("<table width=700 border=1 cellpadding=1 cellspacing=0>");
out.println(
"<tr bgcolor=#ff6666><td>"
+ (++cnum)
+ "</td><td>&nbsp;</td><td><b>"
+ cn
+ "</b></td></tr>");

 

[pete kirkham]

I have two questions about the metric of 'lines of code':


1. How do you actually count this?

For C++ and Java, I have been known to take either the number of
semicolons, or the number of semicolons plus the number of asterices.

2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

I work in R+D for the aerospace industry, so my first professional one
man project involved 400,000+ semicolons (excluding wizard generated
code, and about 250,000 lines made it into production release; that's
the total code that made up all the releases on the project). That
project I was the sole C++ developer creating a experimental toolset for
a group of a dozen engineers over a few years - if there were a dozen
people working on it, then they would just be sitting waiting for the
users to feed back. Most other areas of software are less experimental
and have most of their requirements fixed up front, so can be
implemented by teams on a shorter timescale. Aerospace projects are very
long and thin in comparison.

we would always use NCSL
"non commentary source lines"
for our "C" programs

A more recent project, I was writing an algorithm in C to demonstrate a
deterministic solution to automated collision avoidance in cluttered
airspace. The code is given to the customer to allow it to be ported
onto a realtime, safety critical subsystem. It's highly mathematic, so
contains about 3 lines of comment to one of procedural code - otherwise
it's impossible to follow (if I write something like that without
commenting it, after a month I can't tell what's going on; plain text
based languages don't capture the meaning of math well). That ratio is
fairly typical of critical mathematical code that is intended to be
maintainable. Other languges, such as Spark-ADA, use special comments to
additionally specify the contract of an interface and side effects of a
function.

In non-math applications you often don't need so much explanation, and
higher level languages that are closer to the domain language require
fewer, but the comments should be part of the metric you are using to
mesasure output.

If you don't give value to comments, you are encouraging your developers
to make less maintainable code.


Pete

 

[Joona I Palaste]

Digital Puer <[email protected]> scribbled the following

I have two questions about the metric of 'lines of code':

1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

First you have to decide what constitutes a line of code. Is this a
line of code?

foo(); bar();

What about this?

someFieldSomeWhere=thisIsAReallyLongVariableName.thisIsAReallyLongMethodName
(firstParameter, secondParameter).anotherMethod()!=
A_CONSTANT_WITH_A_REALLY_REALLY_LUDICROUSLY_LONG_NAME;

 

[EventHelix.com]

1. How do you actually count this? On a Unix box, I can run 'wc -l'

to get the lines, but of course this includes comments and blank lines.

The only requirement here is consistency. If you use wc -l for
your entire project, that's fine.

Another mechanism for counting lines of code is to count total number
of semi-colons ( and closing-braces (}).

Sandeep

 

[Jeffrey Palm]

I have two questions about the metric of 'lines of code':


1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

I use this script:

my $total = 0;
my $FORMAT = "%-40s%10d\n";
foreach $infile (@ARGV) {
open(infile, "<$infile") || die "Cannot open $infile:" . $!;
my $cnt = 0;
loop: while (<infile>) {
chomp;
s/^\s+//g;
s/\s+$//g;
foreach $a ("{","}","") {
next loop if $_ eq $a;
}
my $loc = tr/;//;
$cnt += $loc && !/^for/ ? $loc : 1;
}
printf $FORMAT, $infile, $cnt;
$total += $cnt;
close(infile);
}
print "-"x50 . "\n";
printf $FORMAT, "TOTAL", $total;

 

[Joe Wright]

I have two questions about the metric of 'lines of code':

1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

Thanks for any info.

The 'metric' means little. Some of my best work is 300 lines. And took
several days to write (including research, testing..). KLOC is a trap.

 

[Tor Iver Wilhelmsen]

Another mechanism for counting lines of code is to count total number
of semi-colons ( and closing-braces (}).

Except the empty statement is allowed as long as it's reachable.

i++;;;;;;;;;;;;;;;;;;; // KLOC-maker

 

[John W. Krahn]

I use this script:

Oooh! Perl code.

my $total = 0;
my $FORMAT = "%-40s%10d\n";
foreach $infile (@ARGV) {
open(infile, "<$infile") || die "Cannot open $infile:" . $!;
my $cnt = 0;
loop: while (<infile>) {

chomp;
s/^\s+//g;
s/\s+$//g;

The /g option means to match "globally". In other words, to search the
entire string and find every match. However you are using the '^' and
'$' anchors which can only match at one place, the beginning and end of
the string respectively.

foreach $a ("{","}","") {
next loop if $_ eq $a;
}
my $loc = tr/;//;
$cnt += $loc && !/^for/ ? $loc : 1;
}
printf $FORMAT, $infile, $cnt;
$total += $cnt;
close(infile);
}
print "-"x50 . "\n";
printf $FORMAT, "TOTAL", $total;

This is more idiomatic Perl and is also faster in my tests.

my ( $cnt, $total );
my $FORMAT = "%-40s%10d\n";
while ( <> ) {
if ( eof ) {
printf $FORMAT, $ARGV, $cnt;
$total += $cnt;
$cnt = 0;
}
next unless /\S/;
next if /^\s*[}{]\s*$/;
my $loc = tr/;//;
$cnt += $loc && !/^\s*for/ ? $loc : 1;
}
print '-' x 50, "\n";
printf $FORMAT, 'TOTAL', $total;

__END__



John

 

[Chris Smith]

I have two questions about the metric of 'lines of code':

1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

Sorry, there's no industry standard here. It depends on what you want
the number for, and how you think about the question you're trying to
answer. For example, I personally think that counting both comments and
blank lines is a good thing. Anything to value the complexity and
amount of simultaneous stuff happening, rather than just the terseness
of the code form of a solution. Blank lines and comments both represent
additional complexity and more different stuff happening.

I also don't try to outsmart programmers with my line-counting tricks,
and I never shoot for some number of lines whether as a minimum or a
maximum, ESPECIALLY when there's anything on the line for the developer.
I'd much rather not provide incentive for anyone to write anything other
than the best and most readable code they can, just to satisfy some
metric.

As for demonstrating proficiency, it would have to be done by looking at
the code that was written. 5000 lines of code should be plenty to
evaluate someone's level of proficiency, but you can never assume that
someone is proficient just because they've written more lines of code.
The relationship is tenuous at best, and if there is a correlation, it's
more likely in the opposite direction (a lot of lines of code to solve a
simple problem can indicate several serious kinds of lack of proficiency
that I see quite a bit, such as a failure to use available facilities of
the language or third-party libraries properly, or an overly mechanical
and repetitive style of coding that obscures the meaning of the code).

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Jussi Jumppanen]

2. What <.... snip ....>
would show decent proficiency (i.e. for a job interview)?

Here's a novel idea. What about a low bug count

Jussi Jumppanen
Author of: Zeus for Windows (All new version 3.90 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com

 

[Darrell Grainger]

I have two questions about the metric of 'lines of code':


1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

There are scripts that will give you a line count in terms of source code.

It is usually used by bad managers who want to judge your skills based on
the number of lines of code you produce or by the defect ratio (number of
defects per 1000 lines of code or defects/KLOC). The sad thing is, the
moment a programmer knows that management is doing this they tend to write
code like:

if
(expression)
{
do
something
which
should
be
one
line;
}

Even if they don't do that it makes programmers work less to create short
elegant solutions. For example, in second year at university, for a home
work assignment I had to write some code that handled 17 different
situations. I was very impressed with myself. I figured out how to
classify the 17 different cases into 9 equivalence classes and got the
code down to 2 pages. The professors solution did it in 2 equivalence
classes and only 12 lines of code.

If we are measuring skill by lines of code, I was more skilled then my
professor. Obviously not the case.

Since you are not look for this script for the same reason most people
are, do a search for KLOC and you should end up finding it.

2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

The short answer would be 10,000. Just off the top of my head my gut tells
me that writing a 10,000 line program will tend to require the skills of a
proficient programmer.

The long answer is, I have no idea. I have seen code that has a single
function with hundreds of if/elseif/else statements, making the function,
LITERALLY, thousands of lines long. I would have to say that someone who
wrote a three function program that was 10,000 lines long is not someone I
want to hire.

The reality of the situation is that there is more than just the number of
lines written that will determine proficiency. How long has your code been
in use? Did it fail when there was an update to the OS? Has it been
released to the public? How many people are using it? Did you release a
version 2 and 3?

The funny thing is, when I was proficient I knew it. When I'm interviewing
a candidate and asking him questions I tend to know whether or not they
are proficient. I don't have a specific set of questions for determining
proficiency. I will just start chatting with the programmer. If they are
proficient it should become obvious after a few minutes.

 

[Roedy Green]

Blank lines and comments both represent
additional complexity and more different stuff happening.

you could count assignments, and ifs

 

[Roedy Green]

The sad thing is, the
moment a programmer knows that management is doing this they tend to write
code like:

You could measure by the size of the class files if you want a measure
than is independent of comments, and how lines are split.

 

[Thomas Matthews]

I have two questions about the metric of 'lines of code':

Besides the usual argument about how many keywords and statements
can be split across the maximum amount of lines, this metric
does not account for research, requirementes specifications,
requirements reviews, design documents and design reviews.
I also forgot to mention code reviews. As others have stated,
is writing 10,000 lines of bad code better than 500 lines of
good code?

One problem with this metric is that it tends to favor wordy
programs and doesn't measure readable code. My firm belief
is that this metric should be "gone with the wind".

1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

First, one has to set the rules for what a "line of code" is.
After the definition is set, then parsing becomes easier.

2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

No amount of line counting can measure the following important
objectives:
1. Quality: Does the program meet the requirements?

2. Robustness: How bulletproof is the program?

3. Safety: Does the program have any bad side effects?

4. Portability: Can the program be ported easily?

5. Maintainability: Can the program be easily maintained or
have features added?

6. Re-usability: How easily can parts of the program be
used again for other projects?

If your program is 10 lines or 1E06 lines, if it don't work
correctly, it is worthless. If the program crashes every
time it is executed or by a simple user, again length won't
matter. Although one famous company makes a living by producing
poor quality code but placement is their higher priority.
I really hate their outlining algorithm; still has problems
after 5 years.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[Gerry Quinn]

The short answer would be 10,000. Just off the top of my head my gut tells
me that writing a 10,000 line program will tend to require the skills of a
proficient programmer.

It's a reasonable size - my games and screensavers are not gigantic
programs, but they are reasonably complex, and typically weigh in
between 5000 and 10000 semicolons.

For example, my latest game 'Volcano' has 7491 as the total of
semicolons and closing brackets. Some of those are wizard generated, or
not part of the program (utility classes for sprites etc. that I re-use
but have features that are not used in every program).

It might be interesting if someone were to make a list of typical
downloadable software examples of various sizes and the LOC of each. Of
course the real monster programs would probably not be downloadable or
otherwise easily accessible to the public.

Gerry Quinn

 

[Tim Ward]

I have two questions about the metric of 'lines of code':

1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

I don't. I gave up counting lines of code decades ago. It really isn't
useful for anything.

2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

The idea that quantity of code has anything to do with anything you could
mean by proficiency shows lack of anything you could mean by proficiency. I
would be distinctly unimpressed by an interviewee who said "look, I'm good
at this, I can prove it, I've written x thousand lines of code" whatever the
x.

 

[Jos A. Horsmeier]

I don't. I gave up counting lines of code decades ago. It really isn't
useful for anything.


The idea that quantity of code has anything to do with anything you could
mean by proficiency shows lack of anything you could mean by proficiency. I
would be distinctly unimpressed by an interviewee who said "look, I'm good
at this, I can prove it, I've written x thousand lines of code" whatever the
x.

True; when I happen to have a negative LOC-day, I feel very happy.
Removing pages and pages of clumsy code (written by others of course)
and substituting it with a few clever lines (written by me of course ;-)
is a very rewarding exercise.

kind regards,

Jos

 

[Michael J. Fromberger]

Here's a novel idea. What about a low bug count

If only "wc -b" counted bugs the way "wc -l" counts lines.

-M