2012-03-25 2 views
17

Ho il seguente metodo:Java: convenzione per l'utilizzo di javadoc insieme a un'annotazione del metodo?

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

Se voglio aggiungere un Javadoc per questo metodo, c'è qualche convegno su come fare questo con avere l'annotazione @Override (o qualsiasi altra annotazione)?

Il motivo per cui lo chiedo è perché ho letto che i commenti di javadoc DEVONO essere direttamente prima del metodo (nessuna nuova riga tra i due), e non sono sicuro se mettere il commento javadoc direttamente sopra l'annotazione @Override significherebbe cose sopra.

Questo sarebbe il modo convenzionale di farlo per esempio? funziona?

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

C'è sempre uno di voi. Volevo sapere qual era la convenzione, non solo se ha funzionato. – Tim

risposta

16

Sì, in questo modo è la strada giusta, non ho ancora visto il contrario. E sì, funziona così. Non ho provato il contrario.

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

Ma in fondo io di solito vorrei non aggiungere un commento javadoc a un metodo che sovrascrive un altro metodo, in particolare in sede di attuazione delle interfacce. Il tag @inheritDoc è utile qui, per distribuire la documentazione senza grandi sforzi. Ma questo è specifico di questo esempio, potresti aggiungere anche altre annotazioni.

+0

Non sono d'accordo che i metodi sovrascritti non dovrebbero essere documentati. Questo può essere vero con i metodi di interfaccia implementati, ma la documentazione dei metodi delle classi sovrascritte potrebbe indicare cosa è cambiato nel comportamento del metodo. Ovviamente, è possibile evitare molte digitazioni usando il tag Javadoc '@ inheritDoc', ma la documentazione IMO non dovrebbe essere lasciata fuori dai metodi sovrascritti. – buc

+4

Fondamentalmente sono d'accordo con te, ho aggiornato la mia risposta quindi un po '. Ma penso che javadoc sia per documentare ** cosa ** fa un metodo e non ** come ** è fatto. Cambiare il modo in cui qualcosa viene fatto va perfettamente bene, ma un tale cambiamento non dovrebbe violare il contratto definito dalla superclasse che porterebbe alla necessità di cambiare il javadoc allora. Questo è il motivo per cui penso che scrivere un javadoc per ogni metodo non sia necessario. – Markus