Les noms sont nécessaires partout dans le code. En tant que programmeurs, nous devons nommer des classes, des variables, des fonctions, des paramètres, des espaces de noms, etc. Voici 20 conseils pour vous aider à améliorer vos compétences en nommage.

1. Utilisez des noms qui expriment l'intention

Les noms doivent nous dire ce que cela fait, pourquoi cela existe et comment cela fonctionne. Choisir des noms révélateurs d'intention nous facilitera la compréhension du code.

int d; // elapsed time in days

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

Dans l'extrait ci-dessus, nous ne pouvons savoir à quoi la variable d fait référence qu'à partir du commentaire. Ainsi, les lecteurs du code doivent rechercher ses instances pour obtenir des indices afin de comprendre sa signification. Par conséquent, si nous pouvons bien nommer cette variable, les lecteurs du code connaîtront instantanément sa signification.

2. N'ayez pas peur de passer du temps à choisir des noms

Vous devriez essayer plusieurs noms différents jusqu'à ce qu'ils décrivent suffisamment leur signification, et ne jamais avoir peur d'y passer du temps. Ceux qui liront votre code plus tard (y compris vous-même) en bénéficieront. De plus, un nom descriptif peut même vous aider à clarifier la conception du module dans votre esprit. Un bon nommage prend du temps, mais à long terme, les avantages l'emportent sur les coûts.

3. Refactorisez les noms

Si vous pensez à un meilleur nom plus tard dans le développement, n'hésitez pas — allez-y et changez-le. Les IDE d'aujourd'hui rendent le renommage extrêmement facile.

4. Éviter les mots parasites dans les noms

Par exemple,Manager、Processor、Data、Infoet les synonymes de « Je ne sais pas comment appeler ceci » sont tous des mots parasites. Si vous avez besoin d'utiliser ces mots parasites, cela signifie que votre nommage est peut-être trop redondant.

5. Méfiez-vous des classes/fonctions difficiles à nommer

Une classe ou une fonction difficile à nommer est probablement un code smell. Cela indique que :

• Le code en fait trop.
• Le code en fait trop peu.
• Vous ne comprenez pas encore suffisamment bien le problème et devez recueillir plus d'informations.

6. Noms de classes

Les classes doivent avoir des noms qui sont des noms ou des groupes nominaux, tels queCustomer、WikiPage、AccountetAddressParserLes superclasses d'héritage doivent recevoir des noms courts et percutants. Les noms des sous-classes doivent être plus longs, en utilisant des adjectifs pour décrire en quoi elles diffèrent de leur superclasse, tels queSavingsAccountdérivé de Account.

7. Noms de variables

Les noms de variables doivent aussi être des substantifs. La plupart sont dérivés de la classe à laquelle ils se réfèrent. Les variables booléennes doivent être écrites sous forme de prédicats, tels queisEmptyetisTerminated, ce qui les rend plus faciles à comprendre dans les instructions if.

8. Noms de méthodes

Les noms de méthodes doivent être un verbe ou une locution verbale, tels quepostPayment()、deletePage()etsave()Les accesseurs et les mutateurs doivent être préfixés respectivement par get et set. Les méthodes qui renvoient des booléens doivent être préfixées par 'is', comme isPostable(), afin qu'elles soient faciles à comprendre dans les instructions if.

9. Taille de la portée et longueur du nom de variable

La longueur d'un nom de variable doit correspondre à la taille de sa portée. Si la variable a une petite portée, son nom doit être court. À l'inverse, le nom doit être plus long et plus descriptif.

10. Taille de la portée et longueur du nom de méthode/classe

Pour les méthodes et les classes, cependant, la longueur du nom doit être inversement proportionnelle à la portée. Pour les méthodes publiques, des noms plus courts sont préférables car elles sont appelées de nombreuses fois. Les méthodes privées ne sont appelées qu'au sein de la classe, de sorte que des noms plus longs peuvent servir de documentation. L'exception à cette règle concerne les noms des classes dérivées. Plus une classe est dérivée, plus d'adjectifs sont ajoutés avant la classe de base, et plus le nom devient long.

11. Un concept, un mot

Choisissez un mot pour un concept abstrait, puis ne le changez pas. Par exemple, comme méthodes équivalentes dans différentes classes,get()、fetch()andretrieve()peut prêter à confusion. Un vocabulaire cohérent est un outil important pour les programmeurs afin de gérer le code.

12. Ne pas utiliser le même mot pour deux concepts différents

Si vous suivez le point 11 — le principe un concept, un mot — vous pouvez éviter de nombreuses classes ayant le même nom de méthode. Tant que les listes de paramètres et les valeurs de retour des différentes méthodes sont sémantiquement équivalentes, il n'y a pas de problème. Les problèmes ne surviennent que lorsque vous utilisez le même mot pour deux concepts différents.

Par exemple, nous pouvons utiliseradd()la méthode dans plusieurs classes pour créer une nouvelle valeur en ajoutant ou en concaténant deux valeurs existantes. Si plus tard nous devons introduire une méthode add dans une classe pour ajouter un paramètre à une collection, cela causera des problèmes en raison de sémantiques différentes. Il serait préférable de renommer cette nouvelle méthode en insert().

13. Utiliser les noms du domaine de la solution

15. Ajouter un contexte significatif

La plupart des noms sont dénués de sens en eux-mêmes et doivent être placés dans un contexte (classe/fonction/espace de noms) pour que les lecteurs comprennent ce à quoi ils se réfèrent. Dans certains cas, il peut être nécessaire de préfixer les noms pour ajouter du contexte. Par exemple, supposons que nous ayons quelques variables utilisées pour représenter une adresse :firstName、lastName、street、houseNumber、city、stateetzip. Si nous ne regardons que la variable state, il est difficile de déduire ce qu'elle signifie. Une meilleure solution consiste à encapsuler ces variables dans une classe Address.

16. N'ajoutez pas de contexte injustifié

Tant que le sens est clair, les noms courts sont généralement meilleurs que les noms longs, donc n'ajoutez pas de contexte inutilement. Les noms ne doivent pas être préfixés par des informations inutiles qui peuvent être déduites de la classe/du paquet/de l'espace de noms.

17. Évitez l'encodage

Étant donné la puissance des IDE d'aujourd'hui, nous n'avons plus besoin d'encoder les informations de type et de portée dans les noms de variables et de classes. Cela inclut de ne pas avoir à ajouter « I » aux interfaces, car les utilisateurs du code n'ont pas besoin de savoir que leur classe est passée à une interface. Donc, si vous devez utiliser un encodage, il est préférable d'encoder l'implémentation plutôt que l'interface.

18. Évitez les informations trompeuses

Ne donnez pas d'informations trompeuses, car cela induirait les lecteurs du code en erreur. Si vous nommez accountList une variable qui contient en réalité un tableau, il est facile pour les gens d'en tirer une mauvaise conclusion.

19. Évitez les noms imprononçables

La programmation est une activité sociale ; utiliser des noms imprononçables ne fera que gêner nos discussions.

20. Utilisez des noms faciles à rechercher

Utiliser des noms courts et génériques rend difficile la recherche d'éléments dans la base de code. Cela a un grand impact sur notre capacité à manipuler le code et à le refactoriser.

Enfin, si vous avez des avis différents, n'hésitez pas à les partager.

Source : http://www.codeceo.com/article/20-naming-tips-programmer-know.html