commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Inherits doc and @Override
Date Mon, 25 Jul 2011 15:58:38 GMT
On 7/25/11 8:27 AM, Torsten Curdt wrote:
>>> Maybe I am working too much in other languages to appreciate the "less
>>> is more" way of coding.
>>> Self descriptive code is less a myth but more a state of mind when
>>> writing that code and documentation.
>> The problem with that "state of mind" is that unless and until you
>> clearly specify a contract for your code (and write tests to
>> validate it) you - and your users - don't really know what it does.
> With the "state of mind" I mean: think like the user and what matters to him.
> So I am mostly with you - you just haven't have realized that ;)

I get your point.  The problem that I have never been able to solve,
though, is where to draw the line.  My HO is that as soon as you
open the door to people saying "obvious" and omitting method
javadoc, things devolve rather quickly.  This is especially true
when it comes to "self-documenting" method names.  The examples
below certainly look innocuous at first.  But what happens when one
of the setters is changed to have a side effect?  Or when new
constraints are placed on the property?  And where, other than the
getter, do you document what the property means?  I guess when
things become nontrivial, you decide it is no longer "obvious" and
add javadoc.  Again, having been burned by seemingly "obvious" code
many times (including a long and painful experience deciphering
earlier versions of [pool] and [dbcp] that had terrible javadoc), my
admittedly conservative tendency is to want to create the right
documentation structure at the beginning rather than having to keep
track of when things become no longer "obvious."

> No one is saying that describing an API is useless. In fact I am
> saying the exact opposite. I just question the idea of describing
> every method being useful. When you say that the following javadocs
> are useful - then there is probably not much left to discuss anyway:
>     /** Serial */
>     private static final long serialVersionUID = 1234L;
>     /** The Foo's user id. */
>     private int userId;
>     /**
>      * Constructor
>      */
>     public Foo () {
>     /**
>      * Get this Foo's name.
>      *
>      * @return This Foo's name.
>      */
>     public String getName() {
>     /**
>      * Set this Foo's name.
>      *
>      * @param name This Foo's new name.
>      */
>     public void setName(String name) {
> cheers,
> Torsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message