From dev-return-12337-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon Jun 08 14:50:55 2009 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 39538 invoked from network); 8 Jun 2009 14:50:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Jun 2009 14:50:54 -0000 Received: (qmail 78725 invoked by uid 500); 8 Jun 2009 14:51:06 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 78648 invoked by uid 500); 8 Jun 2009 14:51:05 -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 78633 invoked by uid 99); 8 Jun 2009 14:51:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jun 2009 14:51:05 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of michael.d.dick@gmail.com designates 209.85.220.222 as permitted sender) Received: from [209.85.220.222] (HELO mail-fx0-f222.google.com) (209.85.220.222) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jun 2009 14:50:54 +0000 Received: by fxm22 with SMTP id 22so3142336fxm.9 for ; Mon, 08 Jun 2009 07:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vuosNsGrtaesdSY6Op5JLwWRom01MKSUHjysWEP49gk=; b=GN17o7kSlG/FFk9+6nnkuzfwfZTGd0LWRuT169fOl65HZlvLvnmefoezMnnnSZXhSk 8L1lSRQehHLm35c7lHpNc+Ngj/hrTbDBRxUmZEdZ9d+i3/pDocYHnbpTNRmQdhwavg77 ClWUpZjr5GzIuYkI2fqAZWwTsQSAmlyDPTy0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=U2F7nSXRJPJcYXyfpwkNqojM0CJycShdm2e+hNq/KQnvD7Co8DPq0qFWsV8XQRdPq5 37Lq2Ob+05DDs+KyZQLJV6MvVkDsmFY5E/v8fx4UfOkDeI933MbuqBc08DJ/4HCFzXvP IB+PjVuaqfYq7Hfv8VSSQ2keAGh1I8bhPIIgo= MIME-Version: 1.0 Received: by 10.223.125.144 with SMTP id y16mr4171577far.93.1244472630356; Mon, 08 Jun 2009 07:50:30 -0700 (PDT) Date: Mon, 8 Jun 2009 09:50:29 -0500 Message-ID: <72c1350f0906080750r260a4617sd328f8e8a27a98d5@mail.gmail.com> Subject: [DISCUSS] Change line length code convention From: Michael Dick To: dev@openjpa.apache.org Content-Type: multipart/alternative; boundary=00504502e50110e7e5046bd75dbb X-Virus-Checked: Checked by ClamAV on apache.org --00504502e50110e7e5046bd75dbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --00504502e50110e7e5046bd75dbb--