----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol"
<[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 5:46 PM
Subject: Re: [httpclient] new committer
>
> > 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.
ok
>
> > > 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
>
I was exagerating of course but even 25 pages is long. But that's not the
issue. I am fine if we decide to use 100% of the Sun java coding conventions
+ the few items that are not mentionned there. Don't you like the proposal I
have made ?
> >
> > >
> > > 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.
>
The problem is not with CVS; you can plug whatever tool you wish. The
problem is with the tools themselves which are very limited (even the best
one) and only handles a few cases (even the commercial tools).
> >
> > > 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.
>
-Vincent
