commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [EL] Stylistic changes (was: svn commit: r565581)
Date Sat, 18 Aug 2007 14:54:50 GMT
On 8/17/07, Matt Benson <gudnabrsam@yahoo.com> wrote:
>
<snip/>
>
> 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.
<snap/>

Yes, I'd like to see that be the case.


> But to
> examine this further, what are coding conventions but
> the artifact of an agreement between the committers to
> a codebase?
<snip/>

Whatever you can see in the code around the piece you are editing. We
have over time fixed certain checkstyle errors, and we should keep it
at that.


> 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?
<snap/>

Primarily because the new committers may also desert. In the same
vein, if an original committer came back to fix a one-liner, they'd
format the code back to the original style. Then we'd reformat. Or
some such vaguely horrifying scenario.


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

We just can't be bothered. I have learnt to not care about style (in
existing code), as long as its consistent. The kind of formatting done
here leaves the component making quite a confusing style statement.
Further style anarchy (within the same component) can ensue.


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

But surely not style yo-yos.


> 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.  :)
>
<snip/>

I think we should largely respect the (released) component's existing
style / format choices. Nothing else makes much sense to me.

-Rahul


> br,
> Matt
>

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


Mime
View raw message