From dev-return-12351-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon Jun 08 21:28:24 2009 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 24723 invoked from network); 8 Jun 2009 21:28:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Jun 2009 21:28:24 -0000 Received: (qmail 48023 invoked by uid 500); 8 Jun 2009 21:28:36 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 47954 invoked by uid 500); 8 Jun 2009 21:28:36 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 47944 invoked by uid 99); 8 Jun 2009 21:28:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jun 2009 21:28:36 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [62.13.128.88] (HELO outmail128088.authsmtp.com) (62.13.128.88) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jun 2009 21:28:24 +0000 Received: from mail-c189.authsmtp.com (mail-c189.authsmtp.com [62.13.128.71]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n58LS4kX039155 for ; Mon, 8 Jun 2009 22:28:04 +0100 (BST) Received: from [192.168.1.105] (cpe-74-75-138-153.maine.res.rr.com [74.75.138.153]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n58LS1ko063978 for ; Mon, 8 Jun 2009 22:28:02 +0100 (BST) Message-ID: <4A2D825D.3050205@apache.org> Date: Mon, 08 Jun 2009 17:27:57 -0400 From: David Ezzio User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: dev@openjpa.apache.org Subject: Re: [DISCUSS] Change line length code convention References: <72c1350f0906080750r260a4617sd328f8e8a27a98d5@mail.gmail.com> <7f3afc4f.fa8b944.4a2d27f2.8cd95@o2.pl> <4A2D342E.5080000@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Server-Quench: 3f594476-5473-11de-a90b-001f29070be2 X-AuthRoute: OCdyYw0VAlZZQRYI CyQsBTdJQgUoYBpW DgkPIBVyJ0IEUwZJ OwBTNlNYMFBaQktW TWYDRC4RDkJzWWN8 ewhTZwdVaEpMEQJu Tk9MXFNRHBtpBB8e BBscVwZyOVtDcAIT ZB09XnZYVUNyO0N5 R0caFjsDbGNkb2YC VURfdB5VcVcfY05M agJiVHMMN2cOZn1g FQJpKQo8b31sBAVu aTw2FmdaakYCGDEx DxQDGzhnGUADSDkz ZxchJlNUF0EXLEg0 LVomXzpf X-Authentic-SMTP: 61633133353031.kestrel.dmpriest.net.uk:1562/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Checked: Checked by ClamAV on apache.org Looks like I'm going to be in a minority here. I've been around long enough to remember the reason for the 80 character length limit. It predates 13 inch screens, side by side diff comparisons, monochrome consoles, and TTY terminals. The IBM card punch had eighty columns, and it was simply impossible to type beyond the length of the card. If we assume that we no longer have to consider the physical limitations of cards, we can consider what should really drive the limit today. As for side by side diff comparisons, if that were really be our guide, then probably something like 60 characters would be more reasonable. I doubt that any of us would like that. Printers can usually handle 100 to 110 characters without much trouble particularly if you print in landscape mode. I find that with today's wide format screens and the Eclipse IDE which has several useful windows, that 90 columns works pretty well. Although this setting is only 10 extra columns, the extra space seems to be particularly useful in avoiding needless wasted space on screen and on paper. Cheers, David Jeremy Bauer wrote: > 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 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 >>>> >>>> >