You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2004/10/30 19:22:41 UTC
[seda] Coding standards and commit 56039 (by Trustin)
Hi all,
Looks like this commit was to basically reformat and reorganize the
code. I'm cool with that but the Jalopy net affect is to undo my
formatting style which I agree is not the Java standard.
What I ask now, are you following the Java standard with this Jalopy
formating you are using? If not we need to come up with something for
the whole team. I used to use the Avalon coding style and formating.
For me I have bad eyes so I moved to my own style that puts spaces
between stuff so its easier for my eyes. Here's what mine looks like as
opposed to the SUN Java style:
My style has brackets ALWAYS on a new line. I follow this religiously.
Also I put a space between ( and ) as you can see.
public RequestHandler getHandler( Object request )
{
return new NoReplyHandler()
{
public void handle( Object request )
{
}
public HandlerTypeEnum getHandlerType()
{
return HandlerTypeEnum.NOREPLY;
}
};
}
These are the fundamental differences between my style and the Java style below which looks like the SUN Java recommended formatting.
public RequestHandler getHandler(Object request) {
return new NoReplyHandler() {
public void handle(Object request) {
}
public HandlerTypeEnum getHandlerType() {
return HandlerTypeEnum.NOREPLY;
}
};
}
I like mine much better and think the whole damn world is wrong but you
can't piss against the wind and expect not to get wet right? So again
conforming to the standard is best even if it IMO looks less readible.
I will adapt but is this what we want to do. Should we just use the
jakarta coding standards?
Personally I think there are a few good options for us so please add to
this and gimme a check. This is more a poll rather than a formal vote
since we need to feel out what everyone thinks.
[ ] Jakarta standards
[ ] SUN Java recommended standards (might be the same as Jakarta)
[ ] Alex's coding standards
[ ] Geronimo coding standards
[X] mx4j standards but use 4 spaces instead of 3 for tabs
[ ] invent our own
See here:
http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/core/mx4j/AbstractDynamicMBean.java?rev=1.6&view=markup
So people gimme some feedback. In the meantime Trustin please revert
this change for just the formating.
Alex
Re: [seda] Coding standards and commit 56039 (by Trustin)
Posted by Trustin Lee <tr...@gmail.com>.
I prefer what I did at first, but I'm also OK with MX4J style and I
already have jalopy setting for that. :)
On Sat, 30 Oct 2004 13:34:51 -0400, Alex Karasulu <ao...@bellsouth.net> wrote:
> Hiya again,
>
> Ok looking more at the mx4j guy's coding style I think its emaculate.
> These other syles are old and crusty ways of doing things. Personally I
> want stuff to look cleaner and better. Been looking around and talking
> to some commons and Geronimo guys. I think more people want cleaner
> even though this area has been so archaic. They I think find themselves
> having to follow these old standards because a company said so. Looks
> like the standards docs were not updated by SUN since 1999.
>
> Java has come a long way since then and some conventions just don't
> apply anymore. Also I wanted to point out something else that I use as
> a convention. I always use ii, jj, and kk for loop variables and
> learned this from Rob Penoyer. It's the best way to search your code
> for loops cuz I find 'for' in java docs so that's no good and I find
> 'i', 'j' and 'k' everywhere. So you see that this stardard of using
> 'i', 'j' and 'k' for loop variables has a better alternative.
>
> I vote that we invent our own standard using other peoples examples.
> Cleaner coding standards do not raise and set with the SUN Java coding
> standards. Until then please follow the current coding style by
> inferring it. When we have something we should do a checkstyle and a
> Jalopy configuration for that standard and publish it on our site.
>
> Alex
>
>
>
> Alex Karasulu wrote:
>
> > Hi all,
> >
> > Looks like this commit was to basically reformat and reorganize the
> > code. I'm cool with that but the Jalopy net affect is to undo my
> > formatting style which I agree is not the Java standard.
> > What I ask now, are you following the Java standard with this Jalopy
> > formating you are using? If not we need to come up with something for
> > the whole team. I used to use the Avalon coding style and formating.
> > For me I have bad eyes so I moved to my own style that puts spaces
> > between stuff so its easier for my eyes. Here's what mine looks like
> > as opposed to the SUN Java style:
> >
> > My style has brackets ALWAYS on a new line. I follow this
> > religiously. Also I put a space between ( and ) as you can see.
> >
> > public RequestHandler getHandler( Object request )
> > {
> > return new NoReplyHandler()
> > {
> > public void handle( Object request )
> > {
> > }
> >
> > public HandlerTypeEnum getHandlerType()
> > {
> > return HandlerTypeEnum.NOREPLY;
> > }
> > };
> > }
> >
> > These are the fundamental differences between my style and the Java
> > style below which looks like the SUN Java recommended formatting.
> > public RequestHandler getHandler(Object request) {
> > return new NoReplyHandler() {
> > public void handle(Object request) {
> > }
> >
> > public HandlerTypeEnum getHandlerType() {
> > return HandlerTypeEnum.NOREPLY;
> > }
> > };
> > }
> >
> > I like mine much better and think the whole damn world is wrong but
> > you can't piss against the wind and expect not to get wet right? So
> > again conforming to the standard is best even if it IMO looks less
> > readible. I will adapt but is this what we want to do. Should we
> > just use the jakarta coding standards?
> >
> > Personally I think there are a few good options for us so please add
> > to this and gimme a check. This is more a poll rather than a formal
> > vote since we need to feel out what everyone thinks.
> >
> > [ ] Jakarta standards
> > [ ] SUN Java recommended standards (might be the same as Jakarta)
> > [ ] Alex's coding standards
> > [ ] Geronimo coding standards
> > [X] mx4j standards but use 4 spaces instead of 3 for tabs
> > [ ] invent our own
> >
> > See here:
> > http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/core/mx4j/AbstractDynamicMBean.java?rev=1.6&view=markup
> >
> >
> > So people gimme some feedback. In the meantime Trustin please revert
> > this change for just the formating.
> >
> > Alex
> >
> >
>
>
--
what we call human nature in actually is human habit
--
http://gleamynode.net/
Re: [seda] Coding standards and commit 56039 (by Trustin)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Hiya again,
Ok looking more at the mx4j guy's coding style I think its emaculate.
These other syles are old and crusty ways of doing things. Personally I
want stuff to look cleaner and better. Been looking around and talking
to some commons and Geronimo guys. I think more people want cleaner
even though this area has been so archaic. They I think find themselves
having to follow these old standards because a company said so. Looks
like the standards docs were not updated by SUN since 1999.
Java has come a long way since then and some conventions just don't
apply anymore. Also I wanted to point out something else that I use as
a convention. I always use ii, jj, and kk for loop variables and
learned this from Rob Penoyer. It's the best way to search your code
for loops cuz I find 'for' in java docs so that's no good and I find
'i', 'j' and 'k' everywhere. So you see that this stardard of using
'i', 'j' and 'k' for loop variables has a better alternative.
I vote that we invent our own standard using other peoples examples.
Cleaner coding standards do not raise and set with the SUN Java coding
standards. Until then please follow the current coding style by
inferring it. When we have something we should do a checkstyle and a
Jalopy configuration for that standard and publish it on our site.
Alex
Alex Karasulu wrote:
> Hi all,
>
> Looks like this commit was to basically reformat and reorganize the
> code. I'm cool with that but the Jalopy net affect is to undo my
> formatting style which I agree is not the Java standard.
> What I ask now, are you following the Java standard with this Jalopy
> formating you are using? If not we need to come up with something for
> the whole team. I used to use the Avalon coding style and formating.
> For me I have bad eyes so I moved to my own style that puts spaces
> between stuff so its easier for my eyes. Here's what mine looks like
> as opposed to the SUN Java style:
>
> My style has brackets ALWAYS on a new line. I follow this
> religiously. Also I put a space between ( and ) as you can see.
>
> public RequestHandler getHandler( Object request )
> {
> return new NoReplyHandler()
> {
> public void handle( Object request )
> {
> }
>
> public HandlerTypeEnum getHandlerType()
> {
> return HandlerTypeEnum.NOREPLY;
> }
> };
> }
>
> These are the fundamental differences between my style and the Java
> style below which looks like the SUN Java recommended formatting.
> public RequestHandler getHandler(Object request) {
> return new NoReplyHandler() {
> public void handle(Object request) {
> }
>
> public HandlerTypeEnum getHandlerType() {
> return HandlerTypeEnum.NOREPLY;
> }
> };
> }
>
> I like mine much better and think the whole damn world is wrong but
> you can't piss against the wind and expect not to get wet right? So
> again conforming to the standard is best even if it IMO looks less
> readible. I will adapt but is this what we want to do. Should we
> just use the jakarta coding standards?
>
> Personally I think there are a few good options for us so please add
> to this and gimme a check. This is more a poll rather than a formal
> vote since we need to feel out what everyone thinks.
>
> [ ] Jakarta standards
> [ ] SUN Java recommended standards (might be the same as Jakarta)
> [ ] Alex's coding standards
> [ ] Geronimo coding standards
> [X] mx4j standards but use 4 spaces instead of 3 for tabs
> [ ] invent our own
>
> See here:
> http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/core/mx4j/AbstractDynamicMBean.java?rev=1.6&view=markup
>
>
> So people gimme some feedback. In the meantime Trustin please revert
> this change for just the formating.
>
> Alex
>
>
Re: [seda] Coding standards and commit 56039 (by Trustin)
Posted by Trustin Lee <tr...@gmail.com>.
Oh I didn't know that MX4J styles doesn't word-wrap. I think
80-column rules should be kept. :)
On Sat, 06 Nov 2004 09:52:48 -0500, Vincent Tence <vt...@videotron.ca> wrote:
> I second Niclas
>
> [ ] Jakarta standards
> [ ] SUN Java recommended standards (might be the same as Jakarta)
> [x] Alex's coding standards
> [ ] Geronimo coding standards
> [ ] mx4j standards but use 4 spaces instead of 3 for tabs
> [x] invent our own
>
> - Vincent
>
>
>
> On Sat, 2004-11-06 at 13:30 +0800, Niclas Hedhman wrote:
> > On Saturday 06 November 2004 06:29, Enrique Rodriguez wrote:
> > [ ] Jakarta standards
> > [ ] SUN Java recommended standards (might be the same as Jakarta)
> > [x] Alex's coding standards
> > [ ] Geronimo coding standards
> > [ ] mx4j standards but use 4 spaces instead of 3 for tabs
> > [x] invent our own
> >
> > There are a lot in the Mx4j style that are making reading code harder, and
> > should expressly be avoided. Especially;
> >
> > * single line if() constructs or potentially very dangerous
> > * Not following Law of Demeter[1]
> >
> > Other things that are more personal choice;
> >
> > * Consistency in spacing around "(" and ")". The MX4J has space before "("
> > in keywords but not for methods. Personally, I prefer space after "(" and
> > before ")" ALL.
> >
> > * throws clauses on new line for methods.
> >
> >
> > Most importantly, it is a lot harder to read code than write it and hopefully
> > it is also read many more times than it is written, so reading must always
> > take precendence over writing.
> >
> >
> > Cheers
> > Niclas
> >
> > [1]
> > http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html
>
>
--
what we call human nature in actually is human habit
--
http://gleamynode.net/
Re: [seda] Coding standards and commit 56039 (by Trustin)
Posted by Vincent Tence <vt...@videotron.ca>.
I second Niclas
[ ] Jakarta standards
[ ] SUN Java recommended standards (might be the same as Jakarta)
[x] Alex's coding standards
[ ] Geronimo coding standards
[ ] mx4j standards but use 4 spaces instead of 3 for tabs
[x] invent our own
- Vincent
On Sat, 2004-11-06 at 13:30 +0800, Niclas Hedhman wrote:
> On Saturday 06 November 2004 06:29, Enrique Rodriguez wrote:
> [ ] Jakarta standards
> [ ] SUN Java recommended standards (might be the same as Jakarta)
> [x] Alex's coding standards
> [ ] Geronimo coding standards
> [ ] mx4j standards but use 4 spaces instead of 3 for tabs
> [x] invent our own
>
> There are a lot in the Mx4j style that are making reading code harder, and
> should expressly be avoided. Especially;
>
> * single line if() constructs or potentially very dangerous
> * Not following Law of Demeter[1]
>
> Other things that are more personal choice;
>
> * Consistency in spacing around "(" and ")". The MX4J has space before "("
> in keywords but not for methods. Personally, I prefer space after "(" and
> before ")" ALL.
>
> * throws clauses on new line for methods.
>
>
> Most importantly, it is a lot harder to read code than write it and hopefully
> it is also read many more times than it is written, so reading must always
> take precendence over writing.
>
>
> Cheers
> Niclas
>
> [1]
> http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html
Re: [seda] Coding standards and commit 56039 (by Trustin)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 06 November 2004 06:29, Enrique Rodriguez wrote:
[ ] Jakarta standards
[ ] SUN Java recommended standards (might be the same as Jakarta)
[x] Alex's coding standards
[ ] Geronimo coding standards
[ ] mx4j standards but use 4 spaces instead of 3 for tabs
[x] invent our own
There are a lot in the Mx4j style that are making reading code harder, and
should expressly be avoided. Especially;
* single line if() constructs or potentially very dangerous
* Not following Law of Demeter[1]
Other things that are more personal choice;
* Consistency in spacing around "(" and ")". The MX4J has space before "("
in keywords but not for methods. Personally, I prefer space after "(" and
before ")" ALL.
* throws clauses on new line for methods.
Most importantly, it is a lot harder to read code than write it and hopefully
it is also read many more times than it is written, so reading must always
take precendence over writing.
Cheers
Niclas
[1]
http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [seda] Coding standards and commit 56039 (by Trustin)
Posted by Enrique Rodriguez <er...@apache.org>.
[ ] Jakarta standards
[ ] SUN Java recommended standards (might be the same as Jakarta)
[ ] Alex's coding standards
[ ] Geronimo coding standards
[X] mx4j standards but use 4 spaces instead of 3 for tabs
[ ] invent our own
I like the way mx4j doesn't wrap lines. I always thought wrapping at 80
char or whatever was one of those legacy leftovers, too.
-enrique
Alex Karasulu wrote:
> Hi all,
>
> Looks like this commit was to basically reformat and reorganize the
> code. I'm cool with that but the Jalopy net affect is to undo my
> formatting style which I agree is not the Java standard.
> What I ask now, are you following the Java standard with this Jalopy
> formating you are using? If not we need to come up with something for
> the whole team. I used to use the Avalon coding style and formating.
> For me I have bad eyes so I moved to my own style that puts spaces
> between stuff so its easier for my eyes. Here's what mine looks like as
> opposed to the SUN Java style:
>
> My style has brackets ALWAYS on a new line. I follow this religiously.
> Also I put a space between ( and ) as you can see.
>
> public RequestHandler getHandler( Object request )
> {
> return new NoReplyHandler()
> {
> public void handle( Object request )
> {
> }
>
> public HandlerTypeEnum getHandlerType()
> {
> return HandlerTypeEnum.NOREPLY;
> }
> };
> }
>
> These are the fundamental differences between my style and the Java
> style below which looks like the SUN Java recommended formatting.
> public RequestHandler getHandler(Object request) {
> return new NoReplyHandler() {
> public void handle(Object request) {
> }
>
> public HandlerTypeEnum getHandlerType() {
> return HandlerTypeEnum.NOREPLY;
> }
> };
> }
>
> I like mine much better and think the whole damn world is wrong but you
> can't piss against the wind and expect not to get wet right? So again
> conforming to the standard is best even if it IMO looks less readible.
> I will adapt but is this what we want to do. Should we just use the
> jakarta coding standards?
>
> Personally I think there are a few good options for us so please add to
> this and gimme a check. This is more a poll rather than a formal vote
> since we need to feel out what everyone thinks.
>
> [ ] Jakarta standards
> [ ] SUN Java recommended standards (might be the same as Jakarta)
> [ ] Alex's coding standards
> [ ] Geronimo coding standards
> [X] mx4j standards but use 4 spaces instead of 3 for tabs
> [ ] invent our own
>
> See here:
> http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/core/mx4j/AbstractDynamicMBean.java?rev=1.6&view=markup
>
>
> So people gimme some feedback. In the meantime Trustin please revert
> this change for just the formating.
>
> Alex