d_i_r_t_y has asked for the wisdom of the Perl Monks concerning the following question:

can some professional perl-coding monks please give me a final word on whether lines of comments (pod + #...) count in the final tally of lines of code (ie the project is X lines long). naively, i would have thought so, however my friend and colleague disputes this.

secondarily, what is the longest/largest body of perl that monks have written? my current project is over 50,000 lines now (that includes lines of comments ;-) and only modules i have written ), and should be around the 100K mark once finished. Does this constitute 'large' or just 'medium-sized' in the context of perl?

just interested to know...

d_i_r_t_y

Replies are listed 'Best First'.
Zen and the total lines of code
by Abigail (Deacon) on Jun 28, 2001 at 21:24 UTC
    Three programmers applied for a position at the Master. The Master asked each of them how many lines of code they produce daily. The first programmer proudly said "1000". The second programmer boasted "1200". The third programmer wispered she sometimes has "-100" lines on her tally.

    The Master asked the student who he would hire. The second programmer, of course, the student replied.

    The Master hired the third programmer, and the student was enlightened.

    --Abigail

Re: counting total lines of code
by bikeNomad (Priest) on Jun 28, 2001 at 04:43 UTC
    I'm sure others will point this out, but "lines of code" is both hard to count (especially in Perl because of its potential density) and not a particularly useful metric for anything (like scheduling).

    However, if I were counting lines of code for comparison, I'd remove comments and blank lines, as it's the same code without them, and probably run it through perltidy or some other formatter to standardize the format. If you're estimating schedules, you should be able to apply some factor to compare uncommented code with commented code.

    You may want to look into other metrics if you're actually using these numbers for anything other than curiosity. Robert C. Martin proposed some OO ones for C++-like languages in one of his books (sorry, I don't have the title); "cyclomatic complexity" takes into account the number of decision points in your code; there's also "feature point" and "function point" metrics which have the advantage of (theoretically) being computable before you code.

    As far as whether your program is large, I'll let others answer this better, but it seems pretty large to me.

Re: counting total lines of code
by Aighearach (Initiate) on Jun 28, 2001 at 04:38 UTC
    Hopefully we can forever continue to obfuscate the actual KLOCs... it is not only a useless number, but it can be dangerous. Which is better, more or less lines? A better program can be shorter or longer. Also, many Perl projects have portions from included modules. If you use IO::Handle, should you count the lines of Handle.pm also? What about CGI.pm? I've stopped using CGI.pm, instead I cut&paste out the part to stuff a query string into a hash, and the encoding/decoding. So, my version has less lines of code that actually have to be compiled. But, if you're not counting included modules, then my version with less lines compiled counts as more lines. Okay, so if we include CGI.pm's lines, do we only include the lines I used?

    I say leave the KLOCs for the BDSM programmers. ;)
    --
    Snazzy tagline here

Re: counting total lines of code
by petdance (Parson) on Jun 28, 2001 at 06:51 UTC
    The number of lines of code is irrelevant as an absolute number, just like "hits" on a web page. Say your project is 50,000 lines instead of 60,000. What's the difference? What will be done once magic number $nlines is found?

    Where the measurements are important is when comparing two (or twenty) different numbers. Say you've got these measurements on your projects:
    DateLines w/commentsLines w/o comments
    4/1 (Start)00
    5/15,0004,000
    6/110,0007,500
    7/112,00010,000

    You can see that you've been going along at a nice clip for the first two months, and then in June everything slowed down.

    The relationship between lines w/comments and lines w/o doesn't exactly match, but it's close enough for you to say "Hey, look, we're slowing down."

    What's important is that you track it consistently, so that the comparisons are meaningful. In the example above, if you switch measurement from with to without comments, it looks like you've made zero increase in a month, which isn't the case.

    xoxo,
    Andy
    --
    I was dreaming when I wrote this, so sue me if I go too fast.

Re: counting total lines of code
by Beatnik (Parson) on Jun 28, 2001 at 10:08 UTC
    Sticking everything on one line makes it a one-liner. Perl is ideal for exotic line formatting, obfuscation and JAPHs. merlyn can probably rewrite a 5,000 line script in 500 lines (or less). I think you need to ask yourself, do I need 50,000 lines of code? :))))

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.
      Talking about merlyn. He has a script to count lines...column 57 of hise famous webtechniques column :)

      --
      My opinions may have changed,
      but not the fact that I am right

Re: counting total lines of code
by cLive ;-) (Prior) on Jun 28, 2001 at 08:15 UTC
    Lines don't really count - unless you're in the marketing department. My full time job is a bunch of scripts that have now hit 680k/20,000 lines (quick check), but I run them through a shrinker/obfuscator that strips out comments and shortens var names and it goes down to 580k/10,000 lines.

    Guess which figure marketing prefers to use?

    cLive ;-)