When figuring out what "the right amount of code" is, you need to give the people who are liable to pick it up some credit for being intelligent, but not too much. That's a delicate balance. I think of it kind of like this: 
   M/R|      _*_(just right)
    i |     /    \
    l |    /      \
    i |   /        \
    t |  /          \
    y | *(golf)      *(russian novel)
      +----------------
        lines of code

[download]
Too little code and maintainability/readability is lost. People will burn up project time puzzling over a marvelous little snipped of Perl Golf, and will eventually chuck it and rewrite it.

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.

In reply to (dws)Re: Code for readablity or fewer lines? by dws
in thread Code for readablity or fewer lines? by Tuna

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.