10
votes

Comment documenter Args à Java Main

Comment allez-vous de documenter le contenu du paramètre args dans: xxx

Je ne demande pas comment utiliser le @param Étiquette de bloc dans Javadoc, mais comment documenter le contenu de chaque élément de chaque élément doit être.

Par exemple: "args [1] est largeur, args [2] est hauteur. , etc ".

est

  1. la voie à suivre?

5 commentaires

Une considération est que, dans le cas de principal (c'est-à-dire un programme CLI), la plupart des utilisateurs ne lisaient pas le code source. Il existe des bibliothèques de style getOPT pour vous aider à analyser les arguments de la ligne de commande et certains d'entre eux offrent un support de commodité pour l'impression d'informations d'utilisation (telles que dans le cas d'une entrée non valide ou - Aide ).


Utilisez JCommander pour gérer cette


Considérez que les arguments de position ( args [1] signifie FOO, args [2] Barre, etc.) sont beaucoup moins robustes que les arguments nommés ( - FOO = ... , - bar = ... etc.), puisque vous pouvez ajouter et supprimer des arguments, mais oubliez-les de les renuméroter dans la documentation - ou, pire, vous " Vous les avez cuits dans des scripts qui sont parsemés autour de votre codeBase et vous devez ensuite les mettre à jour tous.


En ce qui concerne la documentation, j'irais pour écrire un message d'utilisation et dans le point Javadoc sur ce message d'utilisation. Si le message d'utilisation est défini comme une constante, vous pouvez le désigner directement dans le Javadoc (mais vous pouvez souhaiter que votre message d'utilisation soit localisé, puis vous ne pouvez en faire référence qu'indirectement).


Vous vous demandez simplement: je pense qu'il n'y aura pas beaucoup d'autres réponses ... Considérez donc Accepter La réponse la plus utile ...


3 Réponses :


5
votes

Vous ne pouvez le faire que de manière informelle, en écrivant un texte dans votre Javadoc, qui décrit les arguments attendus .

Signification: Il n'y a pas d'une seule approche correcte ici.

En d'autres termes: vous devez utiliser cette option, qui fonctionne le mieux pour vous et les autres personnes de votre équipe / projet.

Si votre "Team Styleguide" permet (demande?) Vous souhaitez utiliser des balises HTML dans Javadoc, utilisez des balises HTML. Si votre équipe a une approche plus sophistiquée qui permet une sorte de langue marquage , puis utilisez cela. Sinon, vous ne devez probablement utiliser que {@code} pour mettre en évidence certaines parties.

Longue histoire courte: Il n'y a pas de règle exacte ici; Donc, vous devriez au mieux vos besoins .

Mais gardez à l'esprit: Peut-être que la Javadoc est pas si importante à la fin. Si vous pensez que votre application est utilisée directement à partir de la ligne de commande, votre objectif principal devrait être que quelque chose comme «Java -Jar Yourjar --Help» donne une sortie raisonnable. Et que vous ne réintroduisez pas la roue en termes d'analyse «argument». En d'autres termes: il y a beaucoup de bibliothèques là-bas que vous pouvez utiliser pour une analyse de ligne de commande. Et je suis à peu près sûr qu'ils devraient avoir un soutien pour documenter les arguments potentiels des utilisateurs de ligne de commande.

Ce que je dis est: dans une configuration "normale", je m'attendrais à ce que ces personnes intéressées à invoquer votre méthode principale seront pas lire Javadoc. Ils veulent regarder un écran d'aide pour comprendre quelles options ils peuvent utiliser!


0 commentaires

2
votes

Vous êtes à la limite du cadre Java. Arguments sur Main sont fournis par l'environnement d'exécution hôte en tant que réseau de chaînes de caractères. Vous devrez écrire du code pour définir la signification de ces chaînes. Pour d'autres méthodes que vous écrivez, vous déclarerez probablement plusieurs arguments de représenter chaque entrée à cette méthode et utilisez @param Javadoc Syntaxe pour documenter chaque argument.

Voir comment les autres le font: string.format - Bien que cela utilise la syntaxe Vararg, il est sous la hotte convertie en une matrice.

Pour répondre à votre question: il n'y a pas de solution correcte correcte de le faire.


0 commentaires