Also, the compiler is probably more accurate at keeping inherited
documentation up to date.
On Sun, Jul 24, 2011 at 10:52 PM, Jörg Schaible joerg.schai...@scalaris.com
wrote:
Right, and including it creates a placeholder to expand on or modify
the inherited javadoc. I think we should keep
Hi Phil,
Phil Steitz wrote:
On 7/24/11 10:52 PM, Jörg Schaible wrote:
Hi Phil,
Phil Steitz wrote:
On 7/24/11 3:13 PM, Gilles Sadowski wrote:
Hello.
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
Here's the problem as I see it. Code with no javadoc is bad, bad,
bad.
Good code needs little javadocs.
http://vafer.org/blog/20050323095453/
Good docs and good code over noise - any time.
cheers,
Torsten
-
To
Hi Jörg,
- Mail original -
De: Jörg Schaible joerg.schai...@scalaris.com
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 09:19:36
Objet: Re: [math] Inherits doc and @Override
Hi Phil,
Phil Steitz wrote:
On 7/24/11 10:52 PM, Jörg Schaible wrote:
Hi Phil,
Phil Steitz wrote
On 25 July 2011 09:13, Torsten Curdt tcu...@vafer.org wrote:
Here's the problem as I see it. Code with no javadoc is bad, bad,
bad.
+1
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the code implements the docs).
If the only documentation is the code, it is much harder for users to
determine how to use the API.
For
On Mon, Jul 25, 2011 at 5:07 AM, Torsten Curdt tcu...@vafer.org wrote:
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the code implements the docs).
If the only documentation is the code,
I am not saying don't use javadocs. It's all about using javadocs effectively.
Forcing javadocs on all methods leads to bloat and noise. Better
present stellar javadocs on public APIs and document how the library
works. Having great examples helps a great deal ...but don't (please
don't!) use
2011/7/22 Arne Ploese aplo...@gmx.de:
Hi,
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
overwritten methos, so there is no need for @inheritDoc.
If all agree, one could drop this if the code is modified?
On 7/25/11 1:13 AM, Torsten Curdt wrote:
Here's the problem as I see it. Code with no javadoc is bad, bad,
bad.
Good code needs little javadocs.
http://vafer.org/blog/20050323095453/
Good docs and good code over noise - any time.
Ummno.
Without method javadoc, library code is
On 7/25/11 1:36 AM, luc.maison...@free.fr wrote:
Hi Jörg,
- Mail original -
De: Jörg Schaible joerg.schai...@scalaris.com
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 09:19:36
Objet: Re: [math] Inherits doc and @Override
Hi Phil,
Phil Steitz wrote:
On 7/24/11 10:52 PM
] Inherits doc and @Override
Hi Phil,
Phil Steitz wrote:
On 7/24/11 10:52 PM, Jörg Schaible wrote:
Hi Phil,
Phil Steitz wrote:
On 7/24/11 3:13 PM, Gilles Sadowski wrote:
Hello.
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit
On 7/25/11 6:55 AM, Torsten Curdt wrote:
I am not saying don't use javadocs. It's all about using javadocs effectively.
Forcing javadocs on all methods leads to bloat and noise. Better
present stellar javadocs on public APIs and document how the library
works. Having great examples helps a
On 7/25/11 6:31 AM, Matt Benson wrote:
On Mon, Jul 25, 2011 at 5:07 AM, Torsten Curdt tcu...@vafer.org wrote:
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the code implements the docs).
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
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
On Mon, Jul 25, 2011 at 10:27 AM, Torsten Curdt tcu...@vafer.org 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
On 7/24/11 3:13 PM, Gilles Sadowski wrote:
Hello.
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
overwritten methos, so there is no need for @inheritDoc.
If all agree, one could drop this if the code is
Hi Phil,
Phil Steitz wrote:
On 7/24/11 3:13 PM, Gilles Sadowski wrote:
Hello.
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
overwritten methos, so there is no need for @inheritDoc.
If all agree, one
Hi,
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
overwritten methos, so there is no need for @inheritDoc.
If all agree, one could drop this if the code is modified?
20 matches
Mail list logo
