Be sure you don't measure the wrong thing. Read Chapters 21 (How Program Size Affects Construction) and 22 (Managing Construction) of Code Complete (ISBN ISBN 1556154844). It has pragmatical advice that should apply to all languages, even to Perl.

From Table 22.2, p. 545, "Useful Metrics":

Size

• Total lines of code written
• Total comment lines
• Total data declarations
• Total blank lines

Productivity

• Work-hours spent on the project
• Work-hours spent on each routine
• Number of times each routine changed
• Dollars spent on project
• Dollars spent per line of code
• Dollars spent per defect

There are also metrics listed for Defect Tracking, Overall Quality, and Maintainability, but I won't type those in here. Get the book and read it.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

clemburg recommended Code Complete for good coding techniques that improve readablity, optimization, quality, etc. Someone else that reviewed that book also recommended The Software Project Survival Guide and Rapid Development. Does anyone know about these books?

Further, are there books or URLs specifically on solutions and techniques for Perl? (Along the lines of the Cookbook, which I understand is for amateurs and quick hacks.) I have found plenty of resources on syntax and specific uses of various functions, but few that really consider the Perl Approach. :)

Morgan

First of all the Cookbook is not just for amateurs and quick hacks. I find it to be a very valuable resource.

As for good software development, most of that is not very specific to any language. The fundamentals of programming well don't change just because you are programming in Perl now. However among the classics on that topic, the one that I know of with the strongest Perl bent is probably Pragmatic Programmer, The.

For pointers on good Perl style, well books like Effective Perl Programming are meant to address that.

But still there are a plethora of good resources out there. If you do not know the material in them, all of the books that I just mentioned are probably worthwhile to read. Not all at once, of course, but start somewhere and start learning...

"The Software Project Survival Guide" contains a lot of templates and check-lists to impress your manager if you need to. For real-world project planning, you have to see if your project size matches with the intentions of the author (from the intro to "The Software Project Survival Guide": "The plan has been designed with project team sizes of 3 to 25 team members and schedules of 3 to 18 months in mind. These are considered to be medium-sized projects.").

If find the book valuable, but not a "must have", and on the whole much less important to the single programmer than "Code Complete".

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

This sounds flippant, but I count lines with wc -l file. My coding style tends to rely heavily on complex data structures. For instance, I'm looking at one of my scripts that declares a hash of hashes that takes up 28 lines (and 110 chars wide). However by counting semis, that counts as only one line.

It does, however pack an awful lot of functionality away: scalars and coderefs. The code that operates upon it is then pretty simple: it just walks down the keys and tells the values to "do themselves".

What about here documents? What about TR's fed map{}ed arrays in CGI.pm? A line can represent a fearsome amount of code in Perl.

So all in all I just run wc and then get on with the job. If it were enough of an obsession and I was a student with a lot of time on my hands I'd consider writing a module to perform function point analysis.

I like to think of it in a procedure to procedure mannor. Say I have a bit of text data or data structure or some sort of permutation or whatever, more often than not the less number of lines of code(or char's of code in some cases) the better the method of doing that procedure. As well as from my own personal experience, the more and more I code perl the shorter my scripts get :) So as far as amount of work goes with programming, its not(at least for me) the number of lines of code, its how long the programmer spent coding those lines of code.


lindex

/****************************/
  jason@gost.net, wh@ckz.org
    http://jason.gost.net
/*****************************/
[download]

In the words of Blaise Pascal, "This letter is longer than usual because I lack the time to make it short."

-Ted

sub lines_count
{
    open IN, "< $0" || die "Can't open file (black magic?)\n";
    while( <IN> ) {
        chomp;
        printf "%3d: %s\n", $., $_;
    }
    close IN;
}
[download]

perl my_script.pl -e lines_count > something_that_let_you_print. (Maybe) Useful on system where wc does not exist.

Update Sorry, I've said something wrong. From perlrun...

-e commandline
may be used to enter one line of script. If -e is given, Perl will not look for a script filename in the argument list. Multiple -e commands may be given to build up a multi-line script. Make sure to use semicolons where you would in a normal program.

perl -e 'while (<>) {chomp; printf "%3d: %s\n", $., $_; }' < some_script > something_that_let_you_print

Sorry :)

What about the all too (perhaps not completely understood by me) easy

print "Total lines in $0: ". __LINE__ ."\n";

Could you just put that at the end of your script? That would give you your line count wouldn't it?

$ perl cool.pl


My output from the script

Total lines in cool.pl: 37
[download]

Although I admit that the original question is a very good one and one that I am quite interested to see a more "official" answer to. I am still quite new to Perl and I do the wc route to getting my line counts for my scripts. Actually, I do something closer to:

$ egrep -v "^#" script.pl | wc -l

or something more informative...

echo "$(egrep -v "^#" script.pl) - $(egrep "#" script.pl)" | bc
[download]

Which would at least give me my actual lines of code minus my comments. I just finished a script that was 1/3 comments.

----------
- Jim

I don't think he wants line numbers on the code, but rather a line count for the code. But... the following will put line numbers in front of each line:

cat -n filename
[download]

-ben

Line counts are something that bean counters that do not understand software or rather quality software, use as a metric to determine how efficient their programmers are. I could quite easily pump out 1000 lines of crap code per day, and then have to change half of them 3 times and remove 30% to get to a predetermined level of quality, or I can average 1/4 of that, and produce code that has the requested level of quality from the start. Depending on the size of the project I may not code anything for days or weeks, while working through the design. Frequently the well thought out design has fewer lines of code and also has a higher level of quality (fewer lines of code usually means fewer chances to make a mistake).

However, to really answer your question, if some bean counter does ask for such a metric, I usually just give them a wc -l, or possibly, if I'm trying to make them think I've put some real work into the number, I have a script that does a glorified wc -l, but has an impressive name, and a hideous number of comand line switches and 'thinks' about the result for about 45 seconds to a minute, and then prints its result.

Back in my C days, we had a manager who was obsessed with line counts. Not just the data, but he wanted to make sure those lazy programmers weren't inflating their line count by including whitespace, comments, wrapped lines, or anything like that. He eventually came up with a byzantine set of rules he expected us to follow.

In the end, we started running code through the preprocessor before we delivered.

Moral: If you impose arbitrary metrics, programmers will do arbitrary things to reach those metrics.

/me ducks

Rich

(Slightly OT)

You can always use CTRL-G in vi compatible editors, as it usually shows what line you're on, plus how many lines are in the file. ':set number' sure is a useful trick, though.

I'd have to agree with most, though, in that 'wc -l' is probably the best way to measure.

easier: ctrl+g in vi[m] and :set nu (short for :set number)...truncated commands are nice.

----------
- Jim

I got to wondering what people actually measured when called upon. In the end in just took a guestimate with "egrep -c '}|;' <filename>".

Of course, line-count (high or low) by itself means nothing. Don't worry, I fudged a few in my military programming days ;)

Thanks to all for the replies.

Why are you counting your close curly braces? Wouldn't it be better to just count the ';'s? If you are like me and comment a lot (even comment out lines of code for later use) you might want to grep out the '#'s too then count the ';'s.

I still can't think of why you would count the close curlies though.

egrep -v '^#' file | egrep -e ';$' | wc -l
[download]

----------
- Jim

I count the braces so that conditionals and loops count as a line apeice. Admittedly that pulls in subs too (and anonymous hashes, if their closing brace doesn't end on the same line as the semi). It's just a personal preference.

No, EMACS.

That let's you count words as well - very useful for perl files :^)

xoxo,
Andy

# Andy Lester  http://www.petdance.com  AIM:petdance
%_=split';','.; Perl ;@;st a;m;ker;p;not;o;hac;t;her;y;ju';
print map $_{$_}, split //,
'andy@petdance.com'

I'm bemused at how I got modded down three times (as of this writing) for asking a legitimate and helpful question.

We're programmers. It is our job to ask questions. We take user requests and turn them into something useful. Sometimes what the user asks is not what they want. That's where our expertise at problem translation comes into play.

Example #1: The other day, someone from Marketing dropped by asking "Andy, are there any websites with statistics about home computer usage?" I didn't know of any, and some cursory research on Yahoo didn't turn up much useful. Poked around in some online almanacs, but no luck there.

So I delve a little deeper. "Why do you want to know?" I ask. After a few minutes it turns out that what she REALLY wants to know is percentage of homes in the El Paso, TX area that have home computers. Aha, now that's something different. A little research to some Texas gov't websites turns up the answer she was looking for.

Example #2: (And this has happened more times than I care to count) User comes by and asks "How many hits do we get on the website?" Well, that's a pretty wide-ranging question. I used to ask "Do you want hits or sessions or users? Over what time period?" but that causes eye-glaze.

Usually I say "What will you do with the numbers? What if I tell you '5,000'? What will you do with that?" Turns out that I have NEVER had someone ask for web hits that actually has their problem defined.

Now, THAT you can turn into something useful. For instance, I had someone who asked me "how many hits do we get?" because she planned to come back in a month and ask again, and see if it went up because of an ad she was about to run in a magazine. Now, based on that, we can get some meaningful information.

But here's the point... All these answers that have been given to the original poster answer give AN answer, but perhaps not the answer that that poster is looking for. It is our responsibility as monks to make sure that the answer we give is the best one we know how.

xoxo,
Andy

# Andy Lester  http://www.petdance.com  AIM:petdance
%_=split';','.; Perl ;@;st a;m;ker;p;not;o;hac;t;her;y;ju';
print map $_{$_}, split //,
'andy@petdance.com'