I think that, aside dogmatisms, we can try and clarify when, how, and why line breaks and/or longer lines can help us writing comprehensible code. This is, or should be, the purpose of defining style guidelines. My position reads as follows -- expansion, critics, comments welcome.
-1- Use line breaks. Line breaks often help showing the logics of code deeper than, but in a similar way as, python's forced indentation. This is done by splitting complexity into smaller bits visually presented in parallel. They can also help organising literals in a sensible manner. Both often play together to offer "easy to read" (whatever this means) code. This is common for function definitions and function calls, nested container literals, multiline output strings,...
-2- Use long lines. One the other hand, sometimes we wish not to break a line because this would break the logics alltogether. The breaking place would just be arbitrary if there is no logical structure in what we have to split (just to comply with guidelines); so that instead of helping readibility, line breaks introduce "semantic distortion" in such cases. This is common for longer flat containers, single-line string literals and probably some other cases.
-3- How to use line breaks, then?
<my personal problem> While I love using line breaks when they make sense, I often to have no other choice than disregarding the 80-chars rule precisely when breaking lines. The issue is that, in adition to indentation, the continuation line(s) must _visually_ align with items at the same _logical_ level. This level can well be 20 or 30 characters farther on right from the indentation level:
try: my_final_result = finalResultComputer(arg1_from_abunch_of_args, args_should_align_properly, [so, what, if, they, re, compound]) except AttributeError, error: raise computeError( "foo ......... bar" "<--All message text lines should start here." %(String, interpolation, argument, list, as, well) )
[If we do not respect alignment, then the code is semantically wrong. It's like if we would (have to) write for instance: if condition: task1.................................... |80 char limit task2........................................ task3....................................... just to save some indent characters.]
-4- Narrow text even in wide lines! This raises the question of available free width. With both indentation and alignment coming into play, we often have less than 40 characters left. All arguments pro or contra broader lines for legibility thus are irrelevant, because we have rather narrow content anyway ;-
-5- Style Then comes the question of style. Numerous authors have argued that "readibility" or "legibility" simply are masked aliases for "familiarity". On the other hand, a programmer should be able to express things the way s/he really thinks them; to express his or her real meaning and intent. A programmer must be able to feel easy with his or her own code! So that there is a balance to be found between uniformity and personal ease.
As a summary, I would like a recommandation rather than a rule. A note that shows how (0) short line _content_ usually is a sign of good code (*), (1) line breaking can help expressing code structure, (2) but this can require rather big overall line widths, whith leading spacing (3) and in some cases single-lines simply better mirror semantics.
(*) How much, typically?
la vita e estrany