In my experience, line reduction is not a good benchmark for code quality. That's not to say that you shouldn't look for tighter ways to produce your code, but you should do judiciously. Obfuscation is fine for training or entertainment purposes, but it shouldn't be used in production.

I'm a member of the over documentation school, primarily because I have a memory like a steel sieve. If I'm not sure I'll remember why I chose a certain strategy in a week, a month, or a year, I write it down. If it's gonna confuse me, it will likely confuse the person that replaces me.

It's that simple. We're always decrying the lack or quality of documentation with the tools we use. Why, then, would we deliberately contribute to the problem in the tools we write?

For a better treatise on the subject, consider Code Complete. While it might be considered a bit dated by some and the examples are in C, the principles discussed are ones that every professional programmer/developer/anaylst should at least consider. (Also, if you pick up a copy by clicking that link, our tireless leader will get a small kickback.)

I'll second that footpad, coding for clarity is best. People time is more expensive than machine time, and the divergence between the two gets wider every day.

Optimization is good to the point where code starts to lose clarity. Unless the application has to be really optimized. It optimization is the case, then add copius comments so when you or someone else comes back a year later to enhance or fix it - again people time.

I also agree, that I like to over-comment. A year from now I want to know what I was thinking when I go back and look at my code. Besides, comments don't add anything to the actual executable, they are discarded at compile time.

Mike - mps@discomsys.com

"The two most common elements in the universe are hydrogen... and stupidity."
Harlan Ellison

People time is more valuble than machine time.
hehe ... that seems to be the driving motto of perl... :)

if we were all hell-bent on maximum performance, most of us wouldnt be using perl at all but rather assembly or some language of that sort.

i agree with you, readability almost always wins out over line count in my programs, however, dont mistake line count for efficiency line count doesnt always indicate a slower/worse script... sometimes adding a few lines into a script can substantially speed it up.

"I'm a member of the over documentation school, primarily because I have a memory like a steel sieve. If I'm not sure I'll remember why I chose a certain strategy in a week, a month, or a year, I write it down. If it's gonna confuse me, it will likely confuse the person that replaces me"

This rings especially true for me, as I have about a month's worth of programming experience. I am quite certain that I could've done things like use fewer variables and used $key for every single hash key, etc. I chose to use contextual variable names so, I, the inexperienced author, could go back, read, and understand what I have written! For example, $private_file(@private_list) and $public_file(@public_list). Maybe I've gone a little overboard, but my assumption was that someone with little experience could very well end up with this code in their lap. Thanks everyone your perspectives.

sub updateRecord {
  my ($srml_file,$n,$new) = @_;
  my ($offset, $data, $post);
  local $/;

  # no concurrent access, so no locking
  open CACHE, "+< $srml_file" or return setError($!);

  $/ = "<!-- START RECORD $n -->\n";
  <CACHE>;  # get up to the good stuff
  $offset = tell CACHE;

  $/ = "<!-- END RECORD $n -->\n";
  <CACHE>;  # waste what's there

  undef $/;
  $post = <CACHE>;  # get what's left

  seek CACHE, $offset, 0;
  truncate CACHE, $offset;  # in case new data is shorter

  print CACHE
    "<!-- START RECORD $n -->\n",
    getSRML($new),
    "<!-- END RECORD $n -->\n",
    $post;

  close CACHE;

  return -s $srml_file;
}
[download]

The measure of efficiency comes not from the number of lines used, but from the algorithms used. Redundancy can occur in small programs as well as large ones.

japhy -- Perl and Regex Hacker

   M/R|      _*_(just right)
    i |     /    \
    l |    /      \
    i |   /        \
    t |  /          \
    y | *(golf)      *(russian novel)
      +----------------
        lines of code
[download]

Too much code and maintainability/readability is lost. People won't be able to see through the clutter to get at what the code is doing. Or worse, they'll "fix" it correctly, but won't bother updating the shelf-feet of commentary that's cluttering the code up, and maintainability goes down.

Hit the sweet spot, and the code will stay viable and maintainable (or at least stands a good chance of staying that way).

Having done this for a few years decades now, I've found that that code in the sweet spot has a couple of characteristics that are almost language independent.

1. Short methods/subroutines, named for what the method does, not how it does it.
2. Commentary, if any, at the top of a method describes the what, but not the how (unless the how is necesarrily cryptic).
3. Commentary within a method is sparce. (If you find yourself needing to write a lot of commentary inside of a method, that's a big clue that you need to rewrite or refactor.)
4. Loops are nested no more than two deep, and don't span more than a screen If you can't visually spot the top and bottom of the outter loop on a normal display, refactor.
5. Consistent indenting, using logical tabs. (Physical tabs are problematic, especially if people have their editors set up differently.)
6. A consistent philosophy for handling errors. The line between when to throw an exception vs. when to propogate an error code must be well drawn.
7. Appropriate, configurable logging, particularly in bigger system with lots of hands on the code. A good log message is a signpost. It helps people find there way around the system, and doubles as commentary.

For myself, programmer efficiency and readability are on the same side of the coin (if more lines makes it more readable and understandable, I'll spend less time maintaining it later). However, as you might note in this post, sometimes I find making something more readable to my eyes also shortens the code as well (in that case, reducing the number of lines in a loop by half was a side-effect of reducing the level of nested conditionals).

I am oddly reminded of an early thread I was in here at Unique & sorted array optimization?. IMHO shorter is not the goal, it is a result.

For thoughts about a longer (real life) example of that, one of my first posts here was a favorite story of mine from undergrad: The path to mastery.

This really reminds me of the comment in Amadeus: "too many notes".

Seriously, why should your boss care about the number of lines? Did you complete the code in time? Does it work? Is it properly documented and tested? Can it be maintained easily? Those are the important questions.

Now if he doesn't like your coding style maybe he should sit down with you and do a code review, pointing the constructs that he thinks would be improved by being shorter This would give you a chance to learn but also to justify why you chose a more line-consuming method. Then your next project would be better.

But frankly, 300 lines is really a small project and I have no idea why anybody would care. The only reasons I can think of is that either your boss knows that there is a module around that would have cut your code to 20 lines or that he needs to show his boss that Perl is really powerful (in which case it should have let you know in advance).

If your boss knows the language, you have something to defend, since you want good recommendations and repeat business. Point out that you are writing code at the level of those most likely to read it, good maintainable code that doesn't require a knowledge of the choicest idioms to understand.

If on the other hand he's somehow suggesting you are padding the job by writing bulky code, tell him the same thing but add that you can tighten up the work in further assignments, now that you understand the coding practices better.

In either case you've done the write thing, as you seem to know already.

The line between efficiency and readability depends on the function of the code and the person who has to read it next. I write example scripts differently than profound object code that only I'm likely to read. Both make me happy, if they serve both function and audience well.

"Show me your flowcharts and conceal your tables and I will remain mystified; show me your tables, and I won't need your flowcharts, because they will be obvious."
St. Brooks

I think this has a lot to say about maintainability, and what is most important about documentation. Why? Because an understanding of WHAT the program is doing is so much more important in the first stages of handing a program to somebody. After that comes the details - and they should be fairly clear with a complete understanding of what the program is specified to do (barring creature feep).

Most of my comments are based on this - I strive to make my code understandable, but only after I am sure that it is correct and efficient.

"You can do this in fewer lines . . ."
Well, sure - but does it improve the program? Is it faster? Does it use less resources? Is it more modular? Is it more cohesive? Is it loosely coupled enough?

And the number one question: who is going to have to take care of this when you are done with it?

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--

The boss who said "you could do this in fewer lines" probably wants to say something but doesn't know what to say.

Of course you could do this in fewer lines. You could probably do it in one line and enter it in the Obfuscated Perl contest. So what?

I wouldn't worry about your boss's comment too much. It probably just means that he didn't see anything at all wrong with your code.

Laughing...
Does your boss have pointy hair? nooo nevermind...
I would have to agree with sierrathedog04 in the fact that the boss just had to say something authoritative to remind him/herself that they were still boss.


Back to the matter on hand, Code for readability. This helps those following in your footprints and ensures that your code will be used in the future rather than being scrapped because the next person couldn't understand it. It also will prove it was your work when you use that job as a reference.

puts the chalk down and walks away from the board, dusting off his hands