You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Scott Ganyo <sc...@eTapestry.com> on 2002/09/19 20:47:57 UTC
RE: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index F
ieldsReader.java
Ack. Well, that is Sun's idea of "standard Java style," which I rigorously
disagree with. Also, given the amount of Java code that doesn't follow that
style, I would disagree that it is at all "standard." Remember that package
names beginning with all caps like "COM and EDU" used to be Sun's "standard"
style, too, until they got the hint.
Nevertheless, I'm willing to accept that you have defined it as "Lucene
standard style" and I do abide by it when developing Lucene...
Scott
(P.S. Sorry, I realize this is holy-war territory, but I couldn't resist.)
> -----Original Message-----
> From: Doug Cutting [mailto:cutting@lucene.com]
> Sent: Thursday, September 19, 2002 12:12 PM
> To: Lucene Developers List
> Subject: Re: cvs commit:
> jakarta-lucene/src/java/org/apache/lucene/index
> FieldsReader.java
>
>
> Otis,
>
> I really appreciate all of the work you do on Lucene.
> However sometimes
> I have to disagree.
>
> otis@apache.org wrote:
> > - Added FIXME/TODO tags about things to document.
>
> While documentation in a package private class is nice, it is not an
> absolute requirement. So I don't think this warrants a FIXME comment.
>
> > -final class FieldsReader {
> > +final class FieldsReader
> > +{
>
> You also re-indented the code and your indentation style violates
> standard Java style. In Java, opening braces go with the
> previous line,
> not on a line of their own:
>
>
> http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#15395
>
> Doug
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: recommend astyle as indent tool Re: coding conventions
Posted by Otis Gospodnetic <ot...@yahoo.com>.
I agree, but this tool seems to help with indentation only, but there a
number of other rules that one may want standardized.
Anyhow, I think this discussion about people's favourite source code
formatting tools is probably boring to most people here :)
Otis
--- Che Dong <ch...@hotmail.com> wrote:
> Artistic Style
> A Free, Fast and Small Automatic Indentation Filter
> for C , C++ , Java Source Codes
> by Tal Davidson, Israel (E-mail: davidsont@bigfoot.com)
> Main home Page http://astyle.sourceforge.net
> Project Page http://www.sourceforge.net/projects/astyle
>
>
> I think pretty-print source code will make other developers read code
> more efficiently.
>
> Che, Dong
>
> ----- Original Message -----
> From: "Doug Cutting" <cu...@lucene.com>
> To: "Lucene Developers List" <lu...@jakarta.apache.org>
> Sent: Friday, September 20, 2002 5:47 AM
> Subject: coding conventions
>
>
> > Scott Ganyo wrote:
> > > Nevertheless, I'm willing to accept that you have defined it as
> "Lucene
> > > standard style" and I do abide by it when developing Lucene...
> >
> > I don't think style should be (or even can be) mandated. When
> writing
> > new code from scratch, a developer should of course try use a style
> that
> > is not egregiously different than that of the code that it's
> destined to
> > join, but he or she doesn't have to rigidly adhere to an identical
> > style. When editing existing code, a good-faith effort should be
> made
> > to adhere to its existing style. That's just good manners.
> >
> > In general, we should respect the styles of other developers, and
> hope
> > in turn that they will respect our style choices. I don't mind a
> > project with a variety of styles: the personality of the developer
> > should show in the code. I don't even mind a class with different
> > methods coded in different styles if they were written at different
>
> > times and/or by different developers.
> >
> > So I don't think there is a "Lucene standard style". There's my
> style,
> > which accounts for a lot of the code because I wrote a lot of the
> code.
> > But, for example, the German analyzer, which I did not write, is
> in a
> > different style. That's not mayhem, it's just tolerance of
> diversity.
> >
> > Doug
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
recommend astyle as indent tool Re: coding conventions
Posted by Che Dong <ch...@hotmail.com>.
Artistic Style
A Free, Fast and Small Automatic Indentation Filter
for C , C++ , Java Source Codes
by Tal Davidson, Israel (E-mail: davidsont@bigfoot.com)
Main home Page http://astyle.sourceforge.net
Project Page http://www.sourceforge.net/projects/astyle
I think pretty-print source code will make other developers read code more efficiently.
Che, Dong
----- Original Message -----
From: "Doug Cutting" <cu...@lucene.com>
To: "Lucene Developers List" <lu...@jakarta.apache.org>
Sent: Friday, September 20, 2002 5:47 AM
Subject: coding conventions
> Scott Ganyo wrote:
> > Nevertheless, I'm willing to accept that you have defined it as "Lucene
> > standard style" and I do abide by it when developing Lucene...
>
> I don't think style should be (or even can be) mandated. When writing
> new code from scratch, a developer should of course try use a style that
> is not egregiously different than that of the code that it's destined to
> join, but he or she doesn't have to rigidly adhere to an identical
> style. When editing existing code, a good-faith effort should be made
> to adhere to its existing style. That's just good manners.
>
> In general, we should respect the styles of other developers, and hope
> in turn that they will respect our style choices. I don't mind a
> project with a variety of styles: the personality of the developer
> should show in the code. I don't even mind a class with different
> methods coded in different styles if they were written at different
> times and/or by different developers.
>
> So I don't think there is a "Lucene standard style". There's my style,
> which accounts for a lot of the code because I wrote a lot of the code.
> But, for example, the German analyzer, which I did not write, is in a
> different style. That's not mayhem, it's just tolerance of diversity.
>
> Doug
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
Re: coding conventions
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Yeah, forcing is not nice, but even these expectations below is a mild
form of force, and worth documenting, in my opinion. Not everyone will
know what is expected of them.
Furthermore, consistent coding style, even if not one's favourite
style, makes code easier to read and understand, than code with a mix
of styles.
Anyhow, lets move on... :)
Otis
--- Doug Cutting <cu...@lucene.com> wrote:
> Scott Ganyo wrote:
> > Nevertheless, I'm willing to accept that you have defined it as
> "Lucene
> > standard style" and I do abide by it when developing Lucene...
>
> I don't think style should be (or even can be) mandated. When
> writing
> new code from scratch, a developer should of course try use a style
> that
> is not egregiously different than that of the code that it's destined
> to
> join, but he or she doesn't have to rigidly adhere to an identical
> style. When editing existing code, a good-faith effort should be
> made
> to adhere to its existing style. That's just good manners.
>
> In general, we should respect the styles of other developers, and
> hope
> in turn that they will respect our style choices. I don't mind a
> project with a variety of styles: the personality of the developer
> should show in the code. I don't even mind a class with different
> methods coded in different styles if they were written at different
> times and/or by different developers.
>
> So I don't think there is a "Lucene standard style". There's my
> style,
> which accounts for a lot of the code because I wrote a lot of the
> code.
> But, for example, the German analyzer, which I did not write, is in
> a
> different style. That's not mayhem, it's just tolerance of
> diversity.
>
> Doug
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
coding conventions
Posted by Doug Cutting <cu...@lucene.com>.
Scott Ganyo wrote:
> Nevertheless, I'm willing to accept that you have defined it as "Lucene
> standard style" and I do abide by it when developing Lucene...
I don't think style should be (or even can be) mandated. When writing
new code from scratch, a developer should of course try use a style that
is not egregiously different than that of the code that it's destined to
join, but he or she doesn't have to rigidly adhere to an identical
style. When editing existing code, a good-faith effort should be made
to adhere to its existing style. That's just good manners.
In general, we should respect the styles of other developers, and hope
in turn that they will respect our style choices. I don't mind a
project with a variety of styles: the personality of the developer
should show in the code. I don't even mind a class with different
methods coded in different styles if they were written at different
times and/or by different developers.
So I don't think there is a "Lucene standard style". There's my style,
which accounts for a lot of the code because I wrote a lot of the code.
But, for example, the German analyzer, which I did not write, is in a
different style. That's not mayhem, it's just tolerance of diversity.
Doug
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index F ieldsReader.java
Posted by Clemens Marschner <cm...@lanlab.de>.
I would favor again a configuration file for the JRefactory pretty printer
that contains those standards. That pp is available as a cmd line tool and
as an integration with a variety of IDEs, and it guarantees standard
conformance.
Clemens
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index F ieldsReader.java
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Heh. I know, I have (not for Lucene). However, you still need
something firmer in order to be able to point people to, and say "see,
it's defined here, you read it, agred with it, so please follow it".
Anyhow, back to work.
Otis
--- petite_abeille <pe...@mac.com> wrote:
>
> On Thursday, Sep 19, 2002, at 20:48 Europe/Zurich, Otis Gospodnetic
> wrote:
>
> > Other Jakarta projects have the same thing.
>
> Don't waste your time with such triviality... Simply integrate
> checkstyle in your build process.
>
> http://checkstyle.sourceforge.net/
>
> "Checkstyle is a development tool to help programmers write Java code
>
> that adheres to a coding standard. It automates the process of
> checking
> Java code to spare humans of this boring (but important) task. This
> makes it ideal for projects that want to enforce a coding standard.
>
> By default it supports the Sun Code Conventions. However, Checkstyle
> is
> highly configurable."
>
> PA.
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index F ieldsReader.java
Posted by petite_abeille <pe...@mac.com>.
On Thursday, Sep 19, 2002, at 20:48 Europe/Zurich, Otis Gospodnetic
wrote:
> Other Jakarta projects have the same thing.
Don't waste your time with such triviality... Simply integrate
checkstyle in your build process.
http://checkstyle.sourceforge.net/
"Checkstyle is a development tool to help programmers write Java code
that adheres to a coding standard. It automates the process of checking
Java code to spare humans of this boring (but important) task. This
makes it ideal for projects that want to enforce a coding standard.
By default it supports the Sun Code Conventions. However, Checkstyle is
highly configurable."
PA.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-lucene/src/java/org/apache/lucene/index F ieldsReader.java
Posted by Otis Gospodnetic <ot...@yahoo.com>.
To make this type of stuff clear in the future I think we should put a
note about it on the site somewhere (some "developers's corner" area).
In it we can say: follow Sun's Java style standards, except for blah,
blah blah.
Other Jakarta projects have the same thing.
Otis
--- Scott Ganyo <sc...@eTapestry.com> wrote:
> Ack. Well, that is Sun's idea of "standard Java style," which I
> rigorously
> disagree with. Also, given the amount of Java code that doesn't
> follow that
> style, I would disagree that it is at all "standard." Remember that
> package
> names beginning with all caps like "COM and EDU" used to be Sun's
> "standard"
> style, too, until they got the hint.
>
> Nevertheless, I'm willing to accept that you have defined it as
> "Lucene
> standard style" and I do abide by it when developing Lucene...
>
> Scott
>
> (P.S. Sorry, I realize this is holy-war territory, but I couldn't
> resist.)
>
> > -----Original Message-----
> > From: Doug Cutting [mailto:cutting@lucene.com]
> > Sent: Thursday, September 19, 2002 12:12 PM
> > To: Lucene Developers List
> > Subject: Re: cvs commit:
> > jakarta-lucene/src/java/org/apache/lucene/index
> > FieldsReader.java
> >
> >
> > Otis,
> >
> > I really appreciate all of the work you do on Lucene.
> > However sometimes
> > I have to disagree.
> >
> > otis@apache.org wrote:
> > > - Added FIXME/TODO tags about things to document.
> >
> > While documentation in a package private class is nice, it is not
> an
> > absolute requirement. So I don't think this warrants a FIXME
> comment.
> >
> > > -final class FieldsReader {
> > > +final class FieldsReader
> > > +{
> >
> > You also re-indented the code and your indentation style violates
> > standard Java style. In Java, opening braces go with the
> > previous line,
> > not on a line of their own:
> >
> >
> >
>
http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#15395
> >
> > Doug
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>