How understandible a block of code is does not really relate to the length of expressions, but also to the formatting and the names. If the names are well-chosen but long, the formatting should be clear. Together with the way the program is broken up in functions, that determines the accesibility of some code, not whether expressions fit in one line or not.

But the length of an expression determines how it's formatted. Long, multiline expressions are usually harder to understand than smaller expressions fitting on one line. There's a reason why in Python and shell newlines are end of statement indicators! People break up large blocks of code into smaller segments; they do that for some reason. Don't assume that for expressions those reasons no longer hold.

For example, nested or sequential maps are a pain to read when put on a single line.

I don't think nested maps score high on readability, regardless whether done on one line or more.

From another point of view, lines with more than say three or four variable names are probably hard to read anyway. Spreading it out over multiple lines can help than.

Assigning the result of a binary operator where both operands are single variables to a third variable is very common in programming languages like C and Perl. Typically such expressions are one a single line. People are used to that. You cannot convince me easily that splitting them out over multiple lines increases readability. But if your variables are 25 characters, you have the option of either using lines over 80 characters (even if you don't use whitespace around your operators, leave the semi-colon off and don't use identation) or use multiple lines. I'd say, try it out. Write a program that way, and then ask someone else if (s)he wants to maintain it.

About pre/post conditions. Tough topic, when I think of it. A condition is a circumstance before/during/after a function. I would say that such beasts belong to the interface anyway. They can or should be named in the function-name, or be explicitly mentioned in the parameter lists.

Pre- and postconditions belong in the interface, sure. But do you really think that binary_search_on_a_sorted_nonempty_array_containing_integers_floats_or_doubles is a good function name? And what are you going to do if you weaken your precondition? Rewrite every program using the function? How are you going to do that in an OO environment where such things should be hidden from the user? Preconditions can easily take several lines to describe. Do you advocate using names over 80 characters?

-- Abigail