tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Code style rules: Line length
Date Thu, 08 Aug 2013 21:38:32 GMT

On 8/8/13 1:50 PM, Mark Thomas wrote:
> Currently, Tomcat has an 'guide' of a maximum of 80 characters for line
> length. It has been a while since we reviewed this and as we are looking
> at style rules...
> As a starting point what do folks think of the following options:
> Line length:
>  80 - the current
> 100 -
> 120 -

FWIW, there are lots of folks who have word-wrapping GUI code editors
where mostly the line length does make a lick of difference. Until
recently, I used text-mode Emacs for everything and has an 80-line display.

While Emacs does do word-wrapping, it doesn't treat wrapped-lines like
"normal" lines while using arrow keys to navigate (at least not in
whatever mode I was using). So if you are on line 100, column 120 on a
word-wrapped 80-line screen, pressing UP gets you to line 99, column 120
(or the last column on that line if c < 120) instead of line 100 column
40 (which would be directly above line 100, column 120 on the screen).
While this is a mere inconvenience, it's an inconvenience that happens
*all the time* when long lines are often used (and, in this proposal,

While I now use an editor that doesn't exhibit this behavior, I still
tend to stick to 80-column-max for a number of reasons:

1. I still think it's easier to read
2. diffs are still readable on 80-column terminals
3. My devs don't all use the same IDE/editor/etc. and 80-column lines
are generally more consumable

My vote is to stick with 80-column lines when possible. Sometimes, it's
really silly to break a line -- especially when the result is to have
two lines where the first one has 79 columns and the second line has 85
columns of mostly whitespace.

> Strictness
> Informal - the current
> Enforce  - Use checkstyle to enforce whatever limit is chosen

I strongly support informal strictness. Otherwise, we'll end up with
hard-to-read code that is hard-to-read merely because checkstyle is
being stupidly draconian about the rules. I think humans can exercise a
modicum of self-control in this area.

> Pros for longer lines:
> - code easier to read

I think it's /sometimes/ easier to read. Then again, I'm a fan of method
calls that look like this when the lines are longer than maybe 50


This gets IMO more readable when the arguments themselves are method
calls to other things.

> Cons
> - diffs may wrap in mail clients

Yes. I find this very ugly. Unreadable diffs are very frustrating.

> - harder to work with code in a pure text interface (particularly if
> that interface is limited in width to 80 chars)

I do a lot of diff-inspection directly in my terminals (which I keep at

> I have no strong preference on line length but if we do opt for a longer
> length I'd like to see checkstyle enforce the limit.

I do agree with this: I think checkstyle should enforce /some/ arbitrary
(high) limit on line length. Even if we settle on an 80-column
(informal) limit, I think checkstyle should be configured to prohibit,
say, 200-column lines.


View raw message