commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [EL] Stylistic changes (was: svn commit: r565581)
Date Fri, 17 Aug 2007 20:39:10 GMT

--- Dennis Lundberg <dennisl@apache.org> wrote:

> 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.
> 

My obvious +1.

-Matt

> 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
> 
> 



       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

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


Mime
View raw message