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
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
Pre- and postconditions belong in the
interface, sure. But do you really think that
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?
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:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, 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, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||