[junker101]

The number of people here defending long 'darlings' (or over-generalizing 'long one-liners'), is both shocking and dimsaying to me. Beyond basic functionality one of any (serious) programmer's _top_ priorities is to maximize the readability of their code for the next (unkown) programmer that touches the source.

We all have large monitors -often rotated 90degrees to portrait. Extra lines are not a bad thing (especially if it helps visually break things into multiple smaller steps), and more work on a single line does not == elegance.

[parenthephobia]

I consider the priority to be to help maximize the productivity of the next (competent) programmer that touches the source.

Optimizing my source for incompetent programmers isn't something I care about.

Additionally, optimizing the source to aid understanding for competent programmers is only something I care about to the extent that it doesn't otherwise impair their productivity.

Code spread over five lines instead of one might be easier to read, but not necessarily easier to edit.

Code should be written to be easy to edit first, and comments used to patch up where that conflicts with making it easy to understand.

[EdHominem]

We also have nice wide monitors. Tons of short lines with unnecessary names tying them together is usually less clear though, and less robust. (Not that there are only two solutions either.)

Target semi-skilled developers and up, format the code for domain readability and ignore rules that get in the way.