You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2007/08/17 21:13:00 UTC
Re: [EL] Stylistic changes (was: svn commit: r565581)
On 8/13/07, mbenson@apache.org <mb...@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
[1] http://tinyurl.com/2tgo2d
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [EL] Stylistic changes (was: svn commit: r565581)
Posted by Henri Yandell <fl...@gmail.com>.
On 8/17/07, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Rahul Akolkar <ra...@gmail.com> wrote:
>
> > On 8/13/07, mbenson@apache.org <mb...@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
>
> I have tried to compromise by only
> modifying those files in which it is my intent to make
> further changes.
Two thoughts on this.
1) The EL style is irritating. Dropped braces, 80 width files, empty *
lines at the beginning of javadoc, capitalized method names in the
parser. I dislike editing it.
2) Non-surgical changes to EL are going to be HUGELY annoying. We're
going to want to compare back to the Jakarta Standard Taglib, so we
want to be as surgical as possible and not make unnecessary changes.
Bugs in one will be in the other, so we're maintaining a dual codebase
here.
This latter one is crucial I think, so in this case I'm -1 to any
refactorings unless they're applied to both sides. Better to just not
bother.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [EL] Stylistic changes (was: svn commit: r565581)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/17/07, Matt Benson <gu...@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
Re: [EL] Stylistic changes (was: svn commit: r565581)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/17/07, Dennis Lundberg <de...@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?
<snip/>
Yeah, I take those discussions for what they're worth. This wasn't
really about painting all components one way or the other, just
respecting the style choices made by each one.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [EL] Stylistic changes (was: svn commit: r565581)
Posted by Henri Yandell <fl...@gmail.com>.
On 8/17/07, Dennis Lundberg <de...@apache.org> wrote:
> The topic of code style pops up every now and then on this list. Do you
We can't even agree on <p> tags in javadoc :)
<troll>
Why should I, someone who writes web pages sometimes, write bad HTML
to join the consensus (well, 2 other opinions) that prefers sloppy
HTML? It's habit forming.
</troll>
> think that we are ready to create an Apache Commons code style now? I
We have one - in the following order:
**** No tabs.
**** Adhere to the file's existing convention.
**** 120 char width files.
**** Adhere to the Java convention.
There are a few other bits that 'would be nice'.
* A standard name for JUnit test files (get rid of the TestCase.java's).
* One build system (ain't going to happen is it?).
* Standard build system (ie: Use M2, dump M1 and keep the Ant minimal
- with Use Ant, and a minimal M2 for projects which M2 can't support).
> 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.
We've got checkstyle running around enough that maybe the solution is
to just go look at the checkstyles in question and start merging them.
Anyone running checkstyle from vim btw? Presumably I can run it
without having to build the website once we're all on maven2?
For things like EL - we've a lot of leeway for refactoring. Assuming
it's the same as the JSTL formatting, it's not a style I like dealing
with.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [EL] Stylistic changes (was: svn commit: r565581)
Posted by Matt Benson <gu...@yahoo.com>.
--- Dennis Lundberg <de...@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 <ra...@gmail.com> wrote:
> >
> >> On 8/13/07, mbenson@apache.org
> <mb...@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
Re: [EL] Stylistic changes (was: svn commit: r565581)
Posted by Dennis Lundberg <de...@apache.org>.
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 <ra...@gmail.com> wrote:
>
>> On 8/13/07, mbenson@apache.org <mb...@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
Re: [EL] Stylistic changes (was: svn commit: r565581)
Posted by Matt Benson <gu...@yahoo.com>.
--- Rahul Akolkar <ra...@gmail.com> wrote:
> On 8/13/07, mbenson@apache.org <mb...@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