----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol"
<[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 5:19 PM
Subject: Re: [httpclient] new committer
>
>
>
>
> > Regarding coding conventions, I almost agree with you expect on the
> > following points :
> > * When I commit some code, I like to follow the existing coding
conventions
> > so that it is easier to read and understand the code. You can usually do
> > this by following the existing conventions. However, by looking at the
file
> > I have found several conflicting conventions so I am not sure which to
use
>
> I'd have thought that people should follow the coding convention of a
> file, but create new files in their own convention.
that's an idea but I don't like it as it does not lead to consistent code.
>
> > * For debugging, it is very important to have conventions like the one I
> > have proposed otherwise it makes reading log files very hard or
impossible
> > (like logging entry/exits of methods, ...)
>
> I disagree with this part of your proposal. I don't think debugging should
> ever go into a log file. Logging goes to a log file, debugging goes to
> System.err and never gets committed into cvs.
There are different kind of debugging. Fine-grained debugging which you
should do with a java debugger and then debugging/logging which is useful to
uncover bugs/understand strange behaviours when the code is delivered. For
example, imagine a user is having problems with httpclient. You tell him to
turn logs on, and it will generate logs (which are also debugging logs - you
can them whatever you like) that will tell you for instance that it is
because the server is returning 2 cookie headers (set-cookie) and the
httpclient code is not handling it correctly. Without debugging information,
it is much harder to find out.
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 do *really* care if you use tabs instead of spaces because it makes
the
> > code undreadable and is really annoying.
>
> Agreed.
>
>
> 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.
>
> 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.
> 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.
>
> Bay
-Vincent
