Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 86954 invoked from network); 7 Feb 2006 04:45:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Feb 2006 04:45:26 -0000 Received: (qmail 89145 invoked by uid 500); 7 Feb 2006 04:45:24 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 89112 invoked by uid 500); 7 Feb 2006 04:45:24 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 89103 invoked by uid 99); 7 Feb 2006 04:45:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2006 20:45:24 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [210.245.32.200] (HELO localhost.localdomain) (210.245.32.200) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2006 20:45:23 -0800 Received: from [172.16.1.32] (helo=[172.16.1.32]) by localhost.localdomain with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1F6Kio-0005OB-Ku for derby-dev@db.apache.org; Tue, 07 Feb 2006 11:44:58 +0700 Message-ID: <43E825D6.3080400@it.fts-vn.com> Date: Tue, 07 Feb 2006 11:45:10 +0700 From: Kev Jackson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Re: [patch] cleanup of org.apache.derby.iapi.services.cache.ClassSize References: <43E721C5.2050305@it.fts-vn.com> <43E7764D.1080605@sun.com> <43E805BC.2090909@it.fts-vn.com> <43E8205D.1070802@apache.org> In-Reply-To: <43E8205D.1070802@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 {--} X-Spam-Report: Spam detection software, running on the system "mail.fts-vn.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Daniel John Debrunner wrote: >Kev Jackson wrote: > > >>Following on from yesterdays post, here's a patch that tries to get this >>class to conform to the coding standards chosen by the Derby developers >> >> > >Except that we have not chosen a coding standard. :-) > >http://wiki.apache.org/db-derby/DerbyContributorChecklist > > In both coding standards listed (Java Code style from Sun and the Geronimo code style), this class does not conform to either style [...] Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.8 ALL_TRUSTED Did not pass through any untrusted hosts X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Daniel John Debrunner wrote: >Kev Jackson wrote: > > >>Following on from yesterdays post, here's a patch that tries to get this >>class to conform to the coding standards chosen by the Derby developers >> >> > >Except that we have not chosen a coding standard. :-) > >http://wiki.apache.org/db-derby/DerbyContributorChecklist > > In both coding standards listed (Java Code style from Sun and the Geronimo code style), this class does not conform to either style >and in another e-mail: > > >> I'm willing to contribute as I'd like to learn a bit about how databases work under the hood, >>but I can't stand the current code style and I'd like to know if this is an agreed upon convention, >>or a legacy of the various owners of the codebase up to now. >> >> > >The history of the code (from its inception over 8 years ago) was that >the only coding standard in force was to be clear, and don't make >changes in the code just for formatting sake. It was just not worth the >time originally to try and get everyone to agree on a single standard, >some people like braces one way, some the other, some like spaces in >different positions in loops or if statements etc, sometimes a single >rule is not applicable for all situations etc. etc. > > > if (condition) do something; is clear except when you see if (condition) return foo; return bar; (and an example of this can be found in the code that I changed (ie the one in svn right now)) >The issue is that you say you can't stand the current code style, but >maybe someone else can't stand a code style you like, hard to please >everyone. :-) > > > Understood and a good way to compromise is through the enforcement of a standard through something like checkstyle (so the machine is to blame, not a person!) - but note that first I asked about style, then I was directed to two (slightly different) styles linked to from the wiki and this class didn't conform to either of them - hence I assumed that it was worth refactoring a little to conform - also it's not good to have unused imports kicking around, it adds bloat to the code, and it's unnecessary, removing these wouldn't hurt regardless of the rest of the changes. Also I'm suprised that there isn't a defined style (regardless of whether I like it or not) - every single other open source project I've worked on (Java, C, Ruby, whatever) has had a style that submitted patches must conform to before they are considered for inclusion, and it's a little odd that Derby doesn't have this. >Please do get involved in Derby, look at the jira issues marked with a >component of Newcomer, or fix a bug thet scratches your itch with Derby. >Many on the list will be willing to guide you, just ask. > > > >>- remove unused import >>- change static final variables from camelCase to CONST_NAMES (except >>where they are public and could be used elsewhere BWC concern) >> >> >[just curious, what's BWC?] > > BWC = BackWards Compatibility, this is #1 priority over at Ant, so I assumed that no changes should be made to public values/methods to prevent any BWC problems > > >>- add {} for conditionals >>- strip lots of extra white space >> >> > >As Myrna said, these type of changes can cause problems for merges of >fixes across branches and also to others with existing edits against the >same files. > > > >>As for the CLA/ICLA, I've already signed one (for ant), so do I need to >>sign another for Derby? >> >> > >Nope, I belive a single ICLA at the ASF is sufficient. > > Ok, well that's one question answered :) Kev