openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Bauer <techhu...@gmail.com>
Subject Re: [DISCUSS] Change line length code convention
Date Mon, 08 Jun 2009 17:22:12 GMT
It took a while to get used to the 80 limit, but now I like it for the most
part. Like Milosz, I especially like that it facilitates side-by-side
comparisons without the need to scroll horizontally (or the use of a size 4
font).

-Jeremy

On Mon, Jun 8, 2009 at 10:54 AM, Donald Woods <dwoods@apache.org> wrote:

> Yep, same here.  The biggest complaint I have is because of Eclipse and its
> weird behavior in how it does/doesn't wrap lines sometimes.
>
> Now that we have checkstyle setup and it's easy to discover problems during
> a build (without having to rely on Eclipse), I can live with the 80 char
> limit.
>
>
> -Donald
>
>
>
> MiƂosz Tylenda wrote:
>
>> Hi!
>>
>> I used to hate the 80-char limit but then I realized I quite like it when
>> comparing files side-by-side. Now I am neutral.
>>
>> Greetings,
>> Milosz
>>
>>
>>  Starting a separate thread to discuss the merit of 80 / 100 / 120 / {your
>>> favorite length here} line lengths as a code convention.
>>>
>>> Since the project started we've adhered to the Sun code conventions [1]
>>> and
>>> recently introduced changes that enforce this length for source and test
>>> code. This "archaic" limitation has been problematic in many areas, ie
>>> generated metamodel classes.
>>>
>>> I think we can all agree that having some limit to line length is a
>>> benefit
>>> and the real contention is about the specific width in question.
>>>
>>> Sun's conventions justify 80 characters as being required for some
>>> terminals
>>> and tools. The debate has been taken up on several other sites [2],[3],
>>> with
>>> other justifications listed :
>>>  * dispersed development team (some people still have 13" laptop screens)
>>>  * it's easier to have multiple files open
>>>  * going past 80 characters indicates a problem with the code. (ed.
>>> comment
>>> nice)
>>>  * printer friendly
>>>  * plenty more justifications mainly from the comments sections.
>>>
>>> I am not terribly bothered about where we set the limit so long as we
>>> decide
>>> on one and stick to it. Regarding this limit I think Aaron Rubin [4] said
>>> it
>>> best on the python-ideas list (he was talking about how to break lines
>>> though) :
>>>
>>>  * >> This is an unsupported, and IMHO largely incorrect, assumption.
>>>>
>>> *>* >> Several correspondents have noted that they most often overrun
>>> their
>>> *>* >> intended line length by one or two characters.  Just as there's
>>> *>* >> nothing magical about the number "80", there's nothing magical
>>> about
>>> *>* >> "81" or "82" either.  In a regime of 90-character lines, the
limit
>>> *>* >> will most often be exceeded by one or two characters.  The same
>>> will
>>> *>* >> happen in a regime of 100-character lines, etc.  We'll still
need
>>> to
>>> *>* >> break lines, and wrapping them in parentheses will still be the
>>> best
>>> *>* >> way to do that.
>>> *
>>>
>>> We started with 80 character columns and I don't think there's a
>>> compelling
>>> reason to change. I may be in the minority though, and if other devs feel
>>> strongly about this issue I'd encourage them to reply to this thread. If
>>> there's sufficient interest in a wider margin we can then start a [VOTE]
>>> thread.
>>>
>>> [1] http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html
>>> [2]
>>>
>>> http://richarddingwall.name/2008/05/31/is-the-80-character-line-limit-still-relevant/
>>> [3]
>>>
>>> http://stackoverflow.com/questions/758545/maximum-line-length-of-your-ide-checkstyle
>>> [4] http://mail.python.org/pipermail/python-ideas/2009-May/004855.html
>>>
>>> -mike
>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message