> Using System.err, System.out or a java debugger is your own choice but
> please don't commit System.err calls in CVS ... :-) Use the Logging facade
> for that.
I agree. I would suggest that the word logging is used here as it suggests
more of a plan and system than debugging.
> > As far as coding standards go, there is one, it's on Sun's website and it
> > accounts for most issues. Probably the biggest issue that it doesn't cover
> > is where spaces/tabs/newlines go. Lots of IDEs seem to reformat source to
> > a user's preferred settings, which is nice for them but nasty for a
> > project as CVS will be overworked and unable to provide good output.
>
> Yes, but have you seen the size of it. How many of you have read if from
> begginning to end and rememeber everything. What I am saying is to use the
> Sun coding conventions except for the items we mention (not a lot, probably
> 10 max or so). This is simply to ensure everyone has them in mind, instead
> of saying go read the full 400 pages ... And we may decide not to follow all
> of Sun's conventions either.
Obviously not the one I've seen. I keep a printout handy to throw at new
Java programmers along with the javadoc style guide. Both are about 25
pages long.
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
>
> >
> > Equally, CVS could be set so that it reformats all code before
> > committing(?)
> >
>
> ?
>
> You could use Ant with JRefactory for instance and make it part of your
> build process or you could link that with CVS so that it executes it, yes.
> However, in principle it doesn't work perfectly. I have tried it and never
> found it satisfactory.
*nod*
I've never seen anyone really doing this, but it strikes me as the
transparant way it should be done. You cvs commit somethign, it gets
formatted to fit standard. If CVS lacks the technical power, then building
in Ant could also do this.
>
> > I'm sure it's a target for flame, but rather than concentrating on things
> > like formatting of code, I think focus should be on conventions like,
> > never importing wildcards. This is far more painful from my view than how
> > indented a line is etc.
>
> If you wish. However, that's because you don't use an IDE ... In my IDEs, I
> just right click on a class and say "go to class definition" for example or
> simply shift-F1 for javadoc API. But I am fine if we decide to name all
> imports.
>
That's one reason. Reading code with lots of * imports makes it hard to
see what's being used.
Others are that it makes it harder to port from one version of Java to
another (mainly 1.1 to 1.2, but that's not an issue) and it makes it very
hard to port code across package structures. I doubt if either of these
are big issues on a Jakarta project, but they are bigger when dealing with
inexperienced Java programmers.
Lastly there's the classic java.util.* and java.sql.* clash.
