commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [codec] javadoc style
Date Thu, 30 Aug 2012 22:05:50 GMT
On Aug 30, 2012, at 17:58, Christian Hammers <> wrote:

> 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.

There is such magic sadly. The best we can do is a combination of
convention and use of the checkstyle maven plugin.

We do not even have a common checkstyle configuration for commons.
Each component does what it wants.

I'd prefer a common guideline but aside from use spaces and not tabs
there is not much shared.

Ideally it would be nice to store in SVN format config for various
IDEs but that gets messy fast with many IDEs and IDE versions.


>>> 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?
> bye,
> -christian-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message