On 8/17/07, Matt Benson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
