Comment écrire Javadoc de propriétés?


93

Je me trouve souvent face à un dilemme lors de l'écriture de javadoc pour les propriétés / membres d'une classe POJO "simple" ne contenant que des propriétés et des getters et setters (style DTO) ...

1) Ecrire javadoc pour la propriété
ou ...
2) Ecrire javadoc pour le getter

Si j'écris javadoc pour la propriété, mon IDE (Eclipse) ne pourra (naturellement) pas l'afficher lorsque j'accéderai plus tard au POJO via la complétion de code. Et il n'y a pas de balise javadoc standard qui me permette de lier le getter-javadoc à la propriété réelle javadoc.

Un exemple:

public class SomeDomainClass {

  /**
   * The name of bla bla bla
   */
  private String name;

  /**
   * @return INSERT SOME SMART JAVADOC TAG LINKING TO name's javadoc
   */
  public String getName() {  
    return name;  
  }  

Donc, fondamentalement, il serait intéressant d'entendre comment les autres procèdent pour que votre Eclipse IDE affiche la description de la propriété javadoc pour vos getters - sans avoir à dupliquer le commentaire javadoc.

À partir de maintenant, j'envisage de faire ma pratique pour documenter uniquement les getters et non les propriétés. Mais cela ne semble pas être la meilleure solution ...


1
Discussion intéressante à ce sujet ici: stackoverflow.com/questions/1028967/… . La réponse acceptée répond à ce que vous avez demandé sur Eclipse / javadoc.
né le

On dirait qu'ils ont conclu avec ce que j'envisageais ... écrire la propriété javadoc uniquement dans les getters.

J'ai trouvé un moyen de le faire avec des annotations qui fonctionnent dans eclipse et peuvent même être collectées au moment de l'exécution, serait-ce une option?
Aquarius Power

les membres privés ont besoin de javadoc?
cherit

Le nom de bla bla bla: meilleur exemple
Rodrigo Espinoza

Réponses:


75

Vous pouvez inclure des membres privés lors de la génération de Javadocs (en utilisant -private), puis utiliser @link pour créer un lien vers cette propriété de champs.

public class SomeDomainClass {
    /**
     * The name of bla bla bla
     */
    private String name;

    /**
     * {@link SomeDomainClass#name}
     */
    public String getName() {
        return name;
    }
}

Sinon, si vous ne souhaitez pas générer le Javadoc pour tous les membres privés, vous pouvez avoir une convention pour documenter tous les getters et utiliser @link sur les setters.

public class SomeDomainClass {
    private String name;

    /**
     * The name of bla bla bla
     */
    public String getName() {
        return name;
    }

    /**
     * {@link SomeDomainClass#getName}
     */
    public void setName(String name) {
        this.name = name;
    }
}

2
J'ai expérimenté les balises @link et @see .. Mais ... au moins, Eclipse ne l'affiche pas correctement. Eclipse affiche le lien sous forme de lien ... (rouleau de tambour) .... sur lequel il faudra cliquer pour voir le contenu. Je veux pouvoir activer la complétion de code (ou en survolant la souris) pour obtenir le javadoc d'une propriété lorsque je navigue réellement dans un getter ...

13
@Kenny - ne modélisez pas vos pratiques JavaDoc à partir du point de vue de la convivialité d'Eclipse. Faites-le à partir du PDV pour obtenir la sortie JavaDoc correcte (ou suffisamment bonne). Les IDE changent et ce qui pourrait être déficient aujourd'hui pourrait être résolu demain (ou vous pourriez en fait changer complètement les IDE.)
luis.espinal

1
@luis @linksignifie un lien sur lequel il faut cliquer pour voir le javadoc réel. Ce n'est pas un problème d'utilisabilité d'Eclipse, c'est la mauvaise solution pour fournir des javadocs faciles à utiliser.
NateS

4

Lombok est une bibliothèque très pratique pour de telles tâches.

@Getter
@Setter
public class Example {
    /**
     * The account identifier (i.e. phone number, user name or email) to be identified for the account you're
     * requesting the name for
     */
    private String name;
}

C'est tout ce dont vous avez besoin! L' @Getterannotation crée une méthode getter pour chaque champ privé et y attache le javadoc.

PS : la bibliothèque a de nombreuses fonctionnalités intéressantes que vous voudrez peut-être acheter


3

Je fais les deux, aidé par la saisie semi-automatique d'Eclipse.

Tout d'abord, je documente la propriété:

/**
 * The {@link String} instance representing something.
 */
private String someString;

Ensuite, je copie et colle ceci dans le getter:

/**
 * The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

Avec eclipse, les instructions @return ont une saisie semi-automatique - donc, j'ajoute le mot Gets, minuscule le "t" et copie la phrase avec le "t" minuscule. J'utilise ensuite @return (avec la saisie semi-automatique Eclipse), collez la phrase, puis mettez le T en majuscule dans le retour. Cela ressemble alors à ceci:

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

Enfin, je copie cette documentation sur le setter:

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

Ensuite, je le modifie et avec la saisie semi-automatique Eclipse, vous pouvez obtenir non seulement la balise @param mais aussi le nom du paramètre:

/**
 * Sets the {@link String} instance representing something.
 * @param someString The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

Ensuite, j'ai terminé. À mon avis, ce modèle rend beaucoup plus facile, à long terme, non seulement de vous rappeler ce que signifie la propriété par la répétition, mais aussi il est plus facile d'ajouter des commentaires supplémentaires au getter et au setter si vous souhaitez ajouter un côté effets (comme ne pas autoriser les propriétés nulles, transformer les chaînes en majuscules, etc.). J'ai étudié la création d'un plugin Eclipse à cet effet, mais je n'ai pas trouvé le point d'extension approprié pour le JDT, alors j'ai abandonné.

Notez que la phrase peut ne pas toujours commencer par un T - c'est juste la première lettre qui doit être non capitalisée / recapitalisée lors du collage.


23
Le copier / coller est mal ... et prend du temps. Ces étapes ressemblent à beaucoup de travail, et si le javadoc change, vous aurez 3 emplacements différents à mettre à jour. Je ne pense pas qu'un plugin justifierait cela non plus ... au moins, alors le plugin devrait par exemple considérer la propriété javadoc comme étant le maître, puis écraser les getters (et les setters). Ce que je veux accomplir, c'est d'écrire le javadoc en un seul endroit, puis que les getters et les javadocs de propriété assument la même description ...

En règle générale, les propriétés ne changent pas souvent. Et les opérations de copier-coller, avec la saisie semi-automatique d'Eclipse, prennent moins de 30 secondes une fois la propriété Javadoc construite.
MetroidFan2002

4
Je ne suis pas convaincu ... L'introduction de ce type de schéma copier / coller est à mon humble avis liée à conduire à des incohérences. J'ai trop peu confiance dans les autres cuisiniers (ou moi-même) éditant le code plus tard. De plus, au moins si vous n'avez pas une conception initiale complète, les propriétés javadoc sont souvent sujettes à modification, au moins pendant une phase expérimentale / de conception. Et javadoc sera de meilleure qualité s'il est écrit lorsque le code est frais à l'esprit ... Désolé si j'ai l'air d'un pleurnichard ;-)

1
Désolé, mais l'édition des propriétés entraînera forcément des incohérences - dans tous les cas, Javadoc a tendance à tomber à l'écart à moins qu'il ne soit vigoureusement maintenu d'une manière ou d'une autre. Même s'il existait un moyen simple d'exposer la propriété javadoc, il est tout aussi probable que la propriété javadoc elle-même ne soit pas mise à jour. C'est vraiment une question de conventions de codage de l'équipe, etc.
MetroidFan2002

@Metroid - à moins qu'il ne soit vigoureusement maintenu d'une manière ou d'une autre - eh bien, il est censé être vigoureusement maintenu s'il est traité comme faisant partie du code source lui-même. Et ne pas traiter les commentaires Javadoc (et leur équivalent dans d'autres langages) comme une partie intrinsèque du code, bien que ce soit malheureusement la pratique standard, c'est la racine de nombreux maux. Le pire commentaire est celui qui est devenu obsolète. Au mieux, ils ralentissent les programmeurs à maîtriser le code (car ils doivent constamment revalider et accepter / rejeter les commentaires obsolètes.) Au pire, ils donnent des informations sujettes aux erreurs et introduisant des bogues.
luis.espinal

0

Je pense vraiment que c'est un problème et le guide officiel Javadoc ne dit rien à ce sujet. C # peut résoudre cela de manière élégante avec l'utilisation des propriétés (je ne code pas en C #, mais je pense vraiment que c'est une fonctionnalité intéressante).

Mais j'ai une supposition: si vous avez besoin d'expliquer ce qu'est someString, c'est peut-être un `` mauvais petit '' à propos de votre code. Cela peut signifier que vous devriez écrire SomeClass pour taper someString, donc vous expliqueriez ce qu'est someString dans la documentation SomeClass, et juste pour que les javadocs dans getter / setter ne soient pas nécessaires.


1
À propos de l'absence d'utilisation correcte des chaînes dans le code, cochez `` Éviter les chaînes où d'autres types sont plus appropriés '' dans le livre Effective Java.
Leonardo Leite
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.