Section 2.16. Breaking Long Lines


2.16. Breaking Long Lines

Break long expressions before an operator.

When an expression at the end of a statement gets too long, it's common practice to break that expression after an operator and then continue the expression on the following line, indenting it one level. Like so:

     push @steps, $steps[-1] +         $radial_velocity * $elapsed_time +         $orbital_velocity * ($phase + $phase_shift) -         $DRAG_COEFF * $altitude;

The rationale is that the operator that remains at the end of the line acts like a continuation marker, indicating that the expression continues on the following line.

Using the operator as a continuation marker seems like an excellent idea, but there's a serious problem with it: people rarely look at the right edge of code. Most of the semantic hints in a programsuch as keywordsappear on the left side of that code. More importantly, the structural cues for understanding codefor example, indentingare predominantly on the left as well (see the upcoming "Keep Left" sidebar). This means that indenting the continued lines of the expression actually gives a false impression of the underlying structure, a misperception that the eye must travel all the way to the right margin to correct.

Keep Left

The left edge of code is the most prominent location because, like English, Perl is fundamentally a left-to-right language, and in such languages the left-most portion of a statement is most salient.

At the start of a statement, readers are "fresh"; they don't have to remember anything that has gone before. In contrast, by the end of a statement, their short-term memory buffers will be full, they will be preoccupied trying to interpret the whole line, or they may have lost focus entirely.

Linguists call this effect the "end-weight problem" and recommend that important information not be saved till last:

Because, after a long night of hacking, in a horrible dream, there came to me the damnèd souls responsible for ANSI C++, I ran screaming.

Placing that information up front makes it easier to pay attention to it, even if the remainder of the sentence blurs a little:

I ran screaming because the damnèd souls responsible for ANSI C++ came to me in a horrible dream after a long night of hacking.

It's entirely possible to design a programming language where the important stuff comes lastForth and PostScript are two examplesbut, thankfully, Perl isn't that kind of language.


A cleaner solution is to break long lines before an operator. That approach ensures that each line of the continued expression will start with an operator, which is unusual in Perl code. That way, as the reader's eye scans down the left margin of the code, it's immediately obvious that an indented line is merely the continuation of the previous line, because it starts with an operator.

The indenting of the second and subsequent lines of the expression is also critical. Continued lines should not simply be indented to the next indentation level. Instead, they should be indented to the starting column of the expression to which they belong. That is, instead of:

     push @steps, $steps[-1]         + $radial_velocity * $elapsed_time         + $orbital_velocity * ($phase + $phase_shift)         - $DRAG_COEFF * $altitude         ;

you should write:

      push @steps, $steps[-1]                  + $radial_velocity * $elapsed_time                  + $orbital_velocity * ($phase + $phase_shift)                  - $DRAG_COEFF * $altitude                  ; 

This style of layout has the added advantage that it keeps the two arguments of the push visually separated in the horizontal, and thereby makes them easier to distinguish.

When a broken expression is continued over multiple lines, it is good practice to place the terminating semicolon on a separate line, indented to the same column as the start of the continued expression. As the reader's eye scans down through the leading operators on each line, encountering a semicolon instead makes it very clear that the continued expression is now complete.



Perl Best Practices
Perl Best Practices
ISBN: 0596001738
EAN: 2147483647
Year: 2004
Pages: 350
Authors: Damian Conway

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net