I agree with Toby here on most points. I do think that it is a good idea to
have an agreed upon style, though I think that should be a guide only,
leaving it up to the programmer to make the final decision (if it violates
the standard it should be documented why it does so).
How about using the Java Coding Standard by Sun? I would expect that most
Java developers will be familiar with that at the least. It is not perfect,
but if developers can follow 70-80% of them (which isn't hard), then we are
in really good shape.
1 space, 2 space, 3 space, 4. Which indentation quanta to you implore?
I have gone from 2 to 3 and now to 4, and only because I have found that
other open source projects that I have worked on have been mostly 4. So I
have made the switch.
I am happy to go either way, but I am wondering if a quanta of 2 will
attract more developers or turn them off?
Lastly, the bit about persisting the cvs log messages in the source file...
I agree with Toby here and strongly suggest not doing this. It will dirty
up the source and provide a new place for inconsistency (src vs. cvs).
Standards are good, so I am happy to embrace anything along these lines, but
if the goal is to attract more talented developers to help with the project,
it might make sense to use a publicly accepted standard.
--jason
On Tue, 19 Jun 2001, Toby Allsopp wrote:
> Ok, I'm failing to stay out of this argument once again. Crap.
>
> On Mon, Jun 18, 2001 at 08:36:52AM -0700, [EMAIL PROTECTED] wrote:
> > /*
> > - * JBoss, the OpenSource EJB server
> > - *
> > - * Distributable under LGPL license.
> > - * See terms of license at gnu.org.
> > - */
> > +* JBoss, the OpenSource EJB server
> > +*
> > +* Distributable under LGPL license.
> > +* See terms of license at gnu.org.
> > +*/
>
> Huh? Why?
>
> > package x;
> >
> > +//EXPLICIT IMPORTS
> > +import a.b.C1; // GOOD
> > +import a.b.C2;
> > +import a.b.C3;
> >
> > +// DO NOT WRITE
> > +import a.b.*; // BAD
>
> No argument on this.
>
> > +/**
> > +* <description>
> > +*
> > +* @see <related>
> > +* @author <a href="mailto:{email}";>{full name}</a>.
> > +* @author <a href="mailto:[EMAIL PROTECTED]";>Marc Fleury</a>
> > +* @version $Revision: 1.4 $
> > +*
> > +* Revisions:
> > +*
> > +* yyyymmdd author: explicit fix description (no line numbers but methods) go
>beyond the cvs commit message
> > +* eg:
> > +* 20010516 marc fleury: Ask all developers to clearly document the Revision,
>changed the header.
>
> I'm not going to repeat the argument we had a while back about this, but I
> still believe that this is a Very Bad Idea. It will not be maintained because
> it's duplication of work that people already do when they write CVS commit
> logs.
>
> Here's a solution to your perceived problem of not having access to the CVS
> history when offline: maintain a local mirror of the CVS repository on
> your machine.
>
> Also, if you are going to do this, put some HTML in there so that the
> javadocs are readable.
>
> > +// DO NOT USE "TAB" TO INDENT CODE USE *2* SPACES FOR PORTABILITY AMONG EDITORS
>
> Ok, fine. Why *2* spaces all of a sudden? AFAIK, all of the existing code
> is 3 or 4 spaces. In some ways, TABs are better for editor portability
> because people can choose the width of the TABs that they prefer. I prefer
> spaces, however, so I'm not going to argue.
>
> It seems to me that if the goal is to make it as easy as possible for people
> to contribute to JBoss then there should be an absolute minimum of red tape
> and bizzarre coding standards.
>
> Toby.
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
