commons-dev mailing list archives

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

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?

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?

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.

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

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.

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

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


> br,
> Matt

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message