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
signature.asc
Description: OpenPGP digital signature
