commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [EL] Stylistic changes (was: svn commit: r565581)
Date Fri, 17 Aug 2007 20:24:29 GMT
The topic of code style pops up every now and then on this list. Do you 
think that we are ready to create an Apache Commons code style now? I 
hope that we could. It would be a sign of maturity I think. That we have 
grown up. Now I know people get religious when it comes to code style, 
but wouldn't it be better if we could focus on the meaning of the code 
instead of its style? I am willing to help get the necessary support 
resources in place.

Over at Maven we have one Checkstyle configuration file for all of 
Maven, plus configuration files for Eclipse and IDEA to help achieve 
this. Just press the keyboard shortcut to format the code from within 
your IDE before you commit and you're done. During my time there I have 
yet to see a debate regarding code style.

Matt Benson wrote:
> --- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> 
>> On 8/13/07, mbenson@apache.org <mbenson@apache.org>
>> wrote:
>>> Author: mbenson
>>> Date: Mon Aug 13 17:06:29 2007
>>> New Revision: 565581
>>>
>>> URL:
>> http://svn.apache.org/viewvc?view=rev&rev=565581
>>> Log:
>>> format
>>>
>> <snip/>
>>
>> Thanks for looking at [el], it was about time
>> someone stepped up :-)
>>
>> I feel some of the purely stylistic changes (such as
>> this commit)
>> should be avoided, as far as possible. Bit more here
>> [1].
>>
>> -Rahul
> 
> Rahul, I haven't forgotten your earlier objections of
> this nature; I have tried to compromise by only
> modifying those files in which it is my intent to make
> further changes.  I hope you will see this as at least
> somewhat comforting in that "inconsequential" changes
> will only be made in the context of "meaningful" ones.
>  Further, I have attempted to granularize these to
> ease the task of discerning the meaningful changes
> among the superficial.  The particular case in
> question is a preliminary reformatting, though the
> case you cited wrt [jxpath] involved actual functional
> code.  WRT formatting:  further research on my part
> has discovered the note on c.a.o./patches.html to the
> effect that each component has its own coding
> conventions, which should be respected.  But to
> examine this further, what are coding conventions but
> the artifact of an agreement between the committers to
> a codebase?  When the original committers desert and
> new ones must step up, why must this burden be
> augmented by that of being constrained to work within
> some extraordinary set of formatting rules?  IMHO
> Commons should have an "encouraged" set of formatting
> standards; individual components using some other
> format should consider providing one or more resources
> to assist contributors in compliance.  Finally, when
> reviving an unmaintained component, given consensus
> between the involved parties, it should be permissible
> to convert the codebase to an agreeable set of
> formatting rules (hopefully the encouraged Commons
> standard, but theoretically something else).  In both
> the formatting and functional cases, it is my personal
> situation that glaring inefficiencies (unfortunately
> including gratuitous keystrokes) distract my ability
> to focus on the important points of a given task. 
> Most likely this is a mild psychological illness of
> some sort, but some developers are known to express
> the opinion that constant refactoring is an intrinsic
> part of (good) development.  I do agree that if a
> number of developers are working on a codebase and
> certain changes are made back and forth based on the
> whimsy of particular members of the team, that's a
> waste of everyone's time.  But I think such cases can
> and should be democratically settled as individual
> stylistic concerns (e.g. ternary operator vs.
> if-else).
> 
> I hope we can conclude this with some universally
> acceptable solution, though I admit it may well take a
> wiser head than mine to resolve our seemingly
> incompatible stances on the issue.  :)
> 
> br,
> Matt
> 
>> [1] http://tinyurl.com/2tgo2d
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>>
>>
> 
> 
> 
> 
>       ____________________________________________________________________________________
> Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

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


-- 
Dennis Lundberg

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


Mime
View raw message