Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 04 Aug 2006 10:00:35 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-1363) Derby should publish a well
 defined
 coding convention per the db project guidlines
In-reply-to: <44D371EA.80000@sbcglobal.net>
Sender: David.Vancouvering@Sun.COM
To: derby-dev@db.apache.org
Message-id: <44D37D33.403@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <7324787.1154648838711.JavaMail.jira@brutus>
 <x1ox64h9dyem.fsf@sun.com> <44D2B8A2.4080606@apache.org>
 <44D2CC21.90204@sbcglobal.net> <44D371EA.80000@sbcglobal.net>
User-Agent: Thunderbird 1.5.0.2 (X11/20060427)

I agree, we need to be careful about global reformatting; I think the 
biggest issue is around tabs vs. spaces.  If svn diff can ignore white 
space in diffs, that would be great, and we could go ahead and convert 
(carefully) all the code.

I also wouldn't even mind a filter running on svn commit that converts 
all tabs to spaces, if it can be accomplished safely.

David

Mike Matrigali wrote:
> I still don't think it is worth it to reformat all the code style, but
> do think addressing the tab/space issue is worth it. Before we do any
> reformatting I would like to clearly understand the process and any
> likelyhood that the automated reformatter will introduce bugs into the
> code.
> 
> My main problem is the future nightmare of backporting code.  This 
> change will definitely increase the cost/time/likelyhood of backporting
> changes.  For instance most of the store code bracket style is 
> consistent but different than the sun style.  I know eol changes caused
> merges that should have been automatic to turn into hours worth of
> work for me in the past.
> 
> I understand the tab/space issue and think that changing to all spaces
> would help and my hope is that with appropriate flags to patch/svn we
> could get merges to ignore space diffs.
> 
> 
> Kathey Marsden wrote:
>> Daniel John Debrunner wrote:
>>
>>> -1 to defining a new format, why not just pick some existing standard.
>>>
>>> +1 to defining some format.
>>>
>>>  
>>>
>> I will try just a little longer and  then we can just all go back to 
>> our pain.
>> We go with the way the client code is described  but drop the 
>> mandatory braces around blocks so the client code should still fit.
>>
>> <proposal>
>>  Sun default style with 4 space indent (no tabs).
>> </proposal>
>>
>> The Sun default is what is recommended at:
>> http://db.apache.org/source.html
>>
>>
>> Kathey
>>
>>
>>
>