Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Message-ID: <3E770A4B.3020502@apache.org>
Date: Tue, 18 Mar 2003 13:00:11 +0100
From: Cedric Dumoulin <cedric@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: Struts Developers List <struts-dev@jakarta.apache.org>
Subject: Re: cvs commit:
 jakarta-struts/src/share/org/apache/struts/taglib/tiles
 InsertTag.java
References: <20030318024259.16521.qmail@icarus.apache.org>
 <3E76E7B0.4050109@lifl.fr> <3E77029C.6030509@apache.org>
In-Reply-To: <3E77029C.6030509@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Ted Husted wrote:

> Personally, I would say that volunteering to actively maintain a piece 
> of code and creating a bug fix is not reformatting for the sake of 
> reformatting. It is apply the established code conventions to help 
> with fixing an implementation issue.
>
> The code should have "observed the style" of Craig's original codebase 
> when it was first donated. If we all always "observed the style of 
> [our own] original", there would be no conventions at all. 

In this case, the code was donated by me :-). I have first developed it 
following a standard coding. Unfortunately, it is not the Jakarta 
coding, neither the Craig's one. It is to not that I am not the only one 
that think that the Jakarta proposed coding is not the best adapted.
  Will all agree on the basis, and this is the essential. We mainly 
disagree on the place of brackets, and line size. 

>
>
> It would not be useful to change the style to make a very simple 
> correction, or to apply someone else's patch, but if a person needs to 
> analyze the code to resolve a problem, then that is a different matter. 

  Ok, but this rule also apply when I have to maintain the code. The 
applied formatting make me crazy to recognize what I have developed 
myself ! It is why I ask to not change yet the code I have developed , 
and which I mainly maintain. When I have to maintain code from the 
struts core, I don't change the formatting, I simply follow what exist.

>
>
> It's important to note that David posted the stylistic changes first, 
> so that it would be easier to see what changed on the next commit. 
> Since I'm sure the style changes were applied by his IDE, the 
> likelihood introducing a bug this way is negligible. 

  This is a good way to do when we will agree on a format style and 
decide to reformat everything. For now, I think this is not necessary, 
and just a waste of time (reformating, discussing about reformating, 
re-understanding the new formated code, ...).
  I have to correct a bug today, but I have waste all my time on this 
reformating problem.

>
>
> The codebase belongs to the community, and one of our obligations to 
> the community is to provide a reasonably consistent code style. 

  I also agree, but the grain of this consistency can be the roots 
package (struts core, tiles, ...), at least until when we agree/discuss 
on a format and decide to reformat everything ;-) .

 Cedric

>
>
> -T.
>
> Cedric Dumoulin wrote:
>
>>
>>
>> dgraham@apache.org wrote:
>>
>>> dgraham     2003/03/17 18:42:59
>>>
>>>  Modified:    src/share/org/apache/struts/taglib/tiles InsertTag.java
>>>  Log:
>>>  Formatting changes only (in preparation of bug fix).
>>>  
>>>
>>>
>>   May I recall that the consensus is actually to not reformating 
>> classes ?
>>
>>  Check http://jakarta.apache.org/struts/status.html under the Coding 
>> Convention Guidelines, it is written:
>>
>>  "Observe the style of the original". Resist the temptation to make 
>> stylistic changes for their own sake."
>>
>>  Reformating a classes is painful: it introduce useless noise in CVS, 
>> confuse original authors, and don't bring useful things. So please 
>> avoid it.
>>  I know that you don't like my format style. But this is not a valid 
>> reason to reformat it ;-)
>>
>>    Cedric
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org