commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Hammers>
Subject Re: [codec] javadoc style
Date Thu, 30 Aug 2012 21:58:15 GMT
Am Thu, 30 Aug 2012 16:21:43 -0400
schrieb Gary Gregory <>:

> On Thu, Aug 30, 2012 at 2:57 PM, Thomas Neidhart
> <>wrote:
> > Hi,
> >
> > there are quite some differences on the javadoc style in the source
> > files, e.g. the number of spaces before a @param description,
> > whether there is an empty line between @param, @return and @throws.
> >
> I like the default Eclipse formatting style:
>      /**
>      * ...
>      *
>      * @param arg1
>      *            blah blah blah blah
>      * @throws SomeException
>      *            blah blah
>      */

I usually stick with the default Netbeans formatting style which puts
them on the same line. So does the example in the official Java Code
Conventions (I only refer to it if it does things my way *g*)
Doesn't waste so much precious vertical space either :)

Anyway, what I wanted to ask was if there is maybe some kind of pom.xml
magic that tells Eclipse, Netbeans, IDEA etc how we want the formatting
so that we can all continue pressing ctrl-f for reformat before a commit
and be sure that everything looks proper.

> > btw. how do we treat the cases in the package wrt
> > System.err statements? For now I marked them as comment and put a
> > FIXME. The are there in case an unexpected input is read from a
> > resource file at runtime.
> >
> I would probably throw an IllegalArgumentException. You can code that
> and see if the tests all pass.

Using commons-logging and log.warn() would also be an options.
More flexible if the use wants those warnings but of course also
unexpected if no stdout is expected by this class. Is there a way
to get Logger instance that is silent if not explicitly turned on? 



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message