Dans mon en-tête, j'ai une déclaration de prototype comme celle-ci:
/** * Moves the entity to the specified point. * @param x The x coordinate of the new position. * @param y The y coordinate of the new position. */ void move(int, int);
8 Réponses :
C et C ++ sont les mêmes à cet égard. Les noms prototypes n'ont pas besoin de faire correspondre ... c'est pourquoi ils peuvent être omis.
Choisissez des noms pour les paramètres; Lorsque vous les mettez dans DOXYGEN, ils font partie de votre API. Vous pouvez les changer plus tard, mais vous changez l'API; Vous pouvez également les modifier dans la mise en œuvre, mais il ne correspond pas à la spécification aussi proprement.
Ne pas utiliser un double soulignement, même pour les identificateurs "ignorés". Le compilateur peut définir n'importe quoi en commençant par un double soulignement pour signifier quoi que ce soit, ce qui entraîne une erreur de syntaxe. Ces mots ne sont pas simplement interdits pour les noms de variables dans la portée, ils sont complètement toxiques.
Ils n'ont pas à correspondre, mais ils ne peuvent pas être omis dans C. C et C ++ sont différents à cet égard.
@CHARLES, ils peuvent être omis dans C: "Une liste de types de paramètres spécifie les types de, May déclarer des identifiants pour, les paramètres de la fonction" (C99, 6.7.5.3, mes italiques).
Mon erreur, je me suis souvenu d'incorrect. La différence est que, dans c, les noms de paramètres ne peuvent pas être omis dans la fonction Définition , qui est différente de C ++. (D'où l'utilisation plus courante d'une macro non utilisée pour les paramètres de C.)
Ils n'ont pas besoin de faire correspondre, mais je trouve des noms de paramètres pour être une documentation inestimable. Je déteste ça quand on leur manque. J'aime la documentation en code beaucoup mieux que la documentation dans les commentaires.
Et le conseil à la fin de ce lien est vraiment stupide. Les noms de paramètres ne sont rien de spécial en ce qui concerne le risque d'être redéfini par un Non, faites correspondre les noms dans votre implémentation et dans votre en-tête, même si le compilateur ira bien si elles ne le font pas. Et s'ils ne correspondent pas, corrigez-le, alors ils le font. Ils fournissent une excellente documentation et ils seront déroutants s'ils ne correspondent pas. #define . Les noms de fonction et pratiquement tout autre identifiant de votre en-tête sont également en danger. C'est pourquoi la convention de dénomination d'utiliser all_uppercase pour votre #define existe.
+1 - J'ai tendance à être descriptif dans mon fichier d'en-tête, par ex. déplacer (int XCOORD, int Ycoord); Mais ensuite dans ma définition, je pourrais simplement utiliser x, y. Le déplacement pourrait être une ligne / colonne basée sur la colonne, à l'envers de la coordonnée X / Y, par exemple déplacer (int ligne, colonne int); alors déplacez-vous (int, int); Pour certains clients peuvent être interprétés de manière incorrecte sans la documentation ni les paramètres nommés.
Sûrement si "les noms commençant par __ sont interdisés en C ++", vous ne devriez pas les utiliser dans des prototypes non plus :-) * A Je vois deux façons de le faire. < / p> Un, vous pouvez vous assurer que l'ordre des paramètres de vos commentaires correspond toujours à la commande de votre prototype. ou, deux, vous pouvez réellement mettre les noms réels dans vos prototypes aussi . moi-même, je préfère la deuxième approche depuis que j'aime pouvoir dire quels paramètres sont transmis, même si la fonction n'a aucun commentaire sur celui-ci (ou pire, les commentaires sortent de la date). Ceci est beaucoup plus facile avec un prototype comme: qu'avec: dans certains environnements, nous " VE même allé jusqu'à ce que le processus de construction garantit que tous les prototypes de fonction ont des paramètres nommés à l'identique comme définition de la fonction. * a) Ces identificateurs ne sont en réalité pas pour l'utilisation de programmes réguliers. Section 17.6.3.3.2 du CPP0X (mais cette restriction existe depuis un certain temps dans C et C ++) États: Certains ensembles de noms et de signatures de fonction sont toujours réservés à la mise en œuvre:
En d'autres termes, ne les utilisez pas pour vos propres fins.
__ ou commence par un soulignement suivi d'une lettre majuscule est réservée à la mise en œuvre de toute utilisation.
C'est une idée terrible de ne pas nommer les paramètres de l'en-tête s'il n'est pas clair ce que ce paramètre est pour. L'en-tête doit être la documentation de votre code, de sorte que quelqu'un essaye d'utiliser, il peut éviter de lire la mise en œuvre. Comme vous l'avez trouvé, il est inutile de documenter les paramètres par nom et de ne pas dire à l'utilisateur qui est lequel. Cela ne veut pas dire qu'ils doivent correspondre, mais dans l'en-tête, ils devraient avoir un sens pour les utilisateurs de votre code. Dans la mise en œuvre, choisissez le nom qui vous convient le mieux. Par exemple. Il serait totalement réalisable d'avoir:
.h: .cpp: Le seul temps que cela aurait un sens (si vous vous souciez d'autres programmeurs à l'aide de votre code) pour élider les noms de paramètres, c'est quand il est osseux manifestement évident ce que fait ce paramètre. E.g.
J'utilise toujours des noms de paramètres à l'en-tête et dans la mise en œuvre. Il n'est pas difficile de les garder en synchronisation - lorsque je change les paramètres de fonction, je suis généralement:
* Ajouter / Supprimer un paramètre (aucun problème ici - vous devez le synchroniser même si vous n'avez pas utilisé de noms de paramètres)
* Modifier la commande pour être plus logique (à nouveau, même les types doivent être synchronisés)
L'avantage d'avoir les noms de paramètres dans les prototypes et la mise en œuvre est qu'il aide l'utilisateur - il peut voir les noms de son code IDE, il n'a pas à naviguer à la définition (qui pourrait être indisponible) à Découvrez les noms de paramètres. Une autre bonne raison pour coller à cette pratique est votre problème de doxygène.
Je ne vois pas vraiment le point d'utiliser des doubles sous-traitants dans les paramètres de prototype. Oui, #defines sont diaboliques, mais les doubles traits de soulignement sont réservés aux écrivains du compilateur. Sauf si vous écrivez un en-tête standard pour votre compilateur, vous devez l'éviter.
Mauvaise documentation / noms de paramètres est toujours pire qu'aucun nom de documentation / paramètres. Je ne dis pas que vous n'avez pas besoin de documentation ni de noms de paramètres - je dis que vous feriez mieux de les suivre! C'est pourquoi ils nous paient le grand $$$ :-d
Si le fichier d'en-tête appartient à une bibliothèque OEM qui devrait être utilisé par de nombreux vendeurs tiers, des développeurs curieux (tels que ceux qui appartenant à oui) exploreront certainement les fichiers d'en-tête en plus de la documentation fournie, donnée Le fait que la plupart de la documentation de temps soit très mal ou se laisse considérablement derrière le code.
Par conséquent, je dirais que les problèmes cités sur la nommage des paramètres pourraient être une douleur du temps de développement, mais est presque certainement le délice d'un client.
Qu'est-ce que la déclaration du protype est que vous informez Compiler que ce type de fonction va venir avec ces arguments et avec ces types de données. Donc, le compilateur fera des accords pour ce type d'arguments.
Ainsi, le type de données de proto et le nombre d'arguments doit correspondre à la définition réelle et à l'utilisation du temps d'exécution.
Sinon, il donnera une erreur de temps d'exécution.
Le message que vous vous référez à "encourageant" un double sous-traitant de premier plan ne fait rien du genre. L'affiche dit que ce comportement est réservé aux auteurs des compilateurs et des bibliothèques standard. C'est à dire. "Quelqu'un d'autre que toi." :)
Ah ok. Vous semblez tous avoir le même avis à ce sujet, alors je vois cela comme répondit :) J'adorerais marquer toutes les réponses comme «acceptées».