hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <cmcc...@apache.org>
Subject Re: Checkstyle 80 char limit
Date Tue, 05 May 2015 21:19:23 GMT
Historical issues aside, the reasons are:

* When doing vertical, side-by-side diffs, you need some reasonable
length length standard or else it Just Doesn't Work.  And vertical,
side-by-side diffs are how most people prefer to do code reviews.

* Really long lines are visually difficult to follow.  The academic
research is somewhat inconclusive on this topic, but the example of
newspapers, books, magazines, etc. suggests that in practice people do
not want lines that are as wide as possible.  They want and are used
to lines of reasonable length.  There is a reason why newspapers have
multiple columns, and it's not because our printing presses can't do a
single giant column.

* Really long lines encourage excessive nesting (the "Arrow
antipattern" described here: http://c2.com/cgi/wiki?ArrowAntiPattern
).  The more nesting, the more context you need to understand what's
going on.


On Tue, May 5, 2015 at 1:33 PM, Jake Low <jake.low@isilon.com> wrote:
> Quoting Niels Basjes (2015-05-05 11:29:03)
>> So the 80 chars thing was at best reconsidered 16 years ago.
>> Things have changed ...
> Limiting text to a particular width isn't just a byzantine coding convention.
> It arose in programming from much older practices, and it has persisted through
> the years because it improves readability (not just of code, but of any text).
> 80 columns was a fairly standard width for teletypes (and later of video
> terminals). This was mostly a cultural legacy of the IBM punch cards, which
> were 7.375" wide and contained 80 character columns.
> IBM introduced these cards in 1928, but they were not the first of their kind.
> Punched cards have been widely used since the early 19th century to control
> textile looms, mechanical church organs, and various other machines.
> I would posit that the choice of width for punched cards was chosen to match
> the width of printed text. Line length was historically tightly limited;
> sometimes pages would be divided into multiple narrow vertical columns. The
> original edition of the Gutenberg Bible is has a printed text area of about
> 11.7" tall by 8" wide and is divided into two vertical columns, each with about
> 34 characters per line.
> Newspapers and textbooks tend still to adhere to this practice -- they are
> usually printed in very narrow text columns (30 to 50 characters). Other books
> (particularly fiction) tend to be wider, at 60 to 70 characters per line, and
> some websites tend even wider than that.
> I don't believe that there's a particular line length that is optimal for all
> use cases, but I think there are two strong arguments for setting some (fairly
> conservative) line length limit when laying out conventions for code style.
> One is that people will find text most comfortable to read when it is formatted
> in a familiar way. Code is almost universally limited to a maximum of some
> number of characters per line (I've seen 80 most frequently, but also 72, 100,
> and 120).
> Another, which applies specifically to code, is that (unlike most prose) code
> is written in the same format in which it is archived and later read. So,
> unlike the debate about line length for web pages or printed books, the debate
> over code width applies not only to readability but also to *writability*.
> A professor of mine once told me that if I am writing code and reach the end of
> the (80-column) text area, I should pause to ask myself what has gone wrong.
> Perhaps my variable names are too verbose, or perhaps that line contains too
> much logic and should be separated into two lines. I still adhere to this, and
> I find that it consistently improves the quality of the code that I write.
> Perhaps 80 columns isn't the right number (certainly it would vary depending on
> the syntax of the language, conventions related to tab width, and other similar
> factors), but I do find that having such a limit forces me to pause and ask
> myself whether I can be clearer in my expression of the program's logic. I
> think this is a good thing.
> I don't wish to dismiss the option of revisiting the 80-columns convention. I
> only hope to have convinced you that code width is not just a legacy terminal
> compatibily issue -- it has important code quality and readability implications
> too, and those should be carefully considered when creating or updating a style
> guide.
> Best regards,
> -Jake

View raw message