You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Enrique Rodriguez <er...@apache.org> on 2004/11/05 23:29:36 UTC
Re: [seda] Coding standards and commit 56039 (by Trustin)
[ ] 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
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 /
+------//-------------------+