2012-03-25 10 views
17

tengo el siguiente método:Java - ¿Convención para usar javadoc junto con una anotación de método?

@Override 
    public boolean myMethod() 
    { 
     // do stuff 
    } 

Si quiero añadir un javadoc para este método, ¿hay alguna convención sobre cómo hacer esto junto con tener la anotación @ Override (o cualquier otra anotación)?

La razón que pido es porque he leído que los comentarios javadoc deben estar directamente antes del método (no hay saltos de línea entre los dos), y no estoy seguro de si poner el comentario Javadoc directamente por encima de la anotación @ Override ensuciaría cosas claras.

¿Esta sería la forma convencional de hacerlo, por ejemplo? ¿Esto funciona?

/** 
    * This is my method's javadoc comment. 
    */ 
    @Override 
    public boolean myMethod() 
    { 
     // do stuff 
    } 
+5

Siempre hay uno de ustedes. Quería saber cuál era la convención, no solo si funcionaba. – Tim

Respuesta

16

Sí, de esta manera es la forma correcta, no vi al revés. Y sí, de esta manera funciona. No intenté al revés.

/** 
    * This is my method's javadoc comment. 
    */ 
    @Override 
    public boolean myMethod() 
    { 
     // do stuff 
    } 

Pero básicamente me gustaría por lo general no añadir un comentario Javadoc a un método que anula otro método, especialmente en la aplicación de interfaces. La etiqueta @inheritDoc es útil aquí, para distribuir la documentación sin grandes esfuerzos. Pero eso es específico de este ejemplo, también puede agregar otras anotaciones.

+0

No estoy de acuerdo con que los métodos anulados no se documenten. Esto puede ser cierto con los métodos de interfaz implementados, pero la documentación de los métodos de clase anulados podría indicar qué cambió en el comportamiento del método. Por supuesto, se puede evitar mucho tipaje utilizando la etiqueta Javadoc '@ inheritDoc', pero la documentación de IMO no se debe omitir en los métodos anulados. – buc

+4

Básicamente estoy de acuerdo con usted, por lo tanto, actualicé mi respuesta un poco. Pero creo que javadoc es para documentar ** qué ** hace un método y no ** cómo ** está hecho. Cambiar la forma en que se hace algo está perfectamente bien, pero tal cambio no debería violar el contrato definido por la superclase, lo que llevaría a la necesidad de cambiar el javadoc en ese momento. Es por eso que creo que escribir un javadoc para cada método no es necesario. – Markus

Cuestiones relacionadas