Code Formatting was Re: cvs commit: jakarta-struts/src/share/org/apache/...

[David Graham <dg...@hotmail.com>]

The bottom line on this issue is that we already have a standard, the Sun 
Java coding conventions documented here:
http://java.sun.com/docs/codeconv/

When modifying code it is our responsibility to ensure that it meets these 
standards.

David


>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.
>
>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.
>
>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.
>
>The codebase belongs to the community, and one of our obligations to the 
>community is to provide a reasonably consistent code style.
>
>-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
>>
>>
>
>
>--
>Ted Husted,
>Struts in Action <http://husted.com/struts/book.html>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail


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

Re: Code Formatting was Re: cvs commit: jakarta-struts/src/share/org/apache/...

[Cedric Dumoulin <ce...@apache.org>]

  I disagree with you, we don't have a standard. Just take a look to the 
code (not mine, Craig's one ;-) and you will see that we originally 
don't follow completely the Sun standard.
  We follow it for several important things like naming convention and 
javadoc. We don't follow it for the formating part like indentations and 
bracket places.
  I think that the  Sun Java coding conventions has some good things, 
but it also has some bads or deprecated things.
  The code format is always a problem and subject to discussions and 
holly wars. Imagine what will happen if each commiter change the code 
format each time he touch a file ? It is why I ask to refrain 
reformating the code just because you don't like its format.

  Cedric
 

David Graham wrote:

> The bottom line on this issue is that we already have a standard, the 
> Sun Java coding conventions documented here:
> http://java.sun.com/docs/codeconv/
>
> When modifying code it is our responsibility to ensure that it meets 
> these standards.
>
> David
>
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> The codebase belongs to the community, and one of our obligations to 
>> the community is to provide a reasonably consistent code style.
>>
>> -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
>>>
>>>
>>
>>
>> -- 
>> Ted Husted,
>> Struts in Action <http://husted.com/struts/book.html>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
> http://join.msn.com/?page=features/featuredemail
>
>
> ---------------------------------------------------------------------
> 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