db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [Db-derby Wiki] Update of "DerbyContributorChecklist" by RichardHillegas
Date Fri, 24 Feb 2006 18:50:18 GMT
Hi Kristian,

Some responses follow. Cheers-Rick

>> ------------------------------------------------------------------------------ 
>>   ||Copyright Notice||Every java file in your patch must start with 
>> the Apache [http://www.apache.org/licenses/LICENSE-2.0.html#apply  
>> copyright notice]. See the existing Derby Java files for examples. ||
>>   ||Tests||Don't forget to include regression tests with your patch.||
>>   ||Coding Standards||The Derby community has not approved a common 
>> body of coding standards. Individual contributors have found the 
>> following standards useful: 
>> [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html  Java 
>> Coding Standards] and 
>> [http://wiki.apache.org/geronimo/CodingStandards  Geronimo Coding 
>> Standards].||
>> + ||Comments||Make sure you comment your code.||
>> + ||Tabs||Set your tabs at 4 spaces. This was the original Cloudscape 
>> convention. With this setting your code should look readable.||
> Hi,
> I know the issue has been discussed before, but is it deliberate that 
> the checklist does not specify whether it is preferred to use tabs or 
> spaces for indentation?

The checklist is trying to stay neutral and not recommend policies which 
the community hasn't agreed yet.

> While I'm at it, if we say spaces are preferred over tabs, is it okay 
> to contribute patches that (only) fix indentation for individual files?
> The primary reason for doing this (for me) is that files that mix 
> space and tab indentation can result in very ugly diffs.
> As mentioned earlier, most editors/IDEs are able to cope with this 
> issue, so it's no problem when working with the code in these tools.
I seem to recall from the last discussion of this issue: There was some 
concern that large-scale cosmetic changes would complicate the porting 
of bug fixes from unscrubbed branches and from other in-flight 
subversion clients. Maybe we could address this problem by homogenizing 
the mainline just before we cut the next branch. We might have enough 
time to agree on a policy by then.

View raw message