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.