tomcat-dev mailing list archives

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

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,
encouraged).

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
characters:

methodCall(argument1,
           argument2,
           argument3,
           argument4,
           argument5);

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
80-columns).

> 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.

-chris


Mime
View raw message