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 votre capacité de nommage.

1. Utilisez des noms qui révèlent l'intention

Un nom doit nous dire ce qu'il fait, pourquoi il existe et comment il fonctionne. Choisir des noms qui révèlent l'intention nous facilite 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 pouvons seulement savoir à partir du commentaire à quoi la variable d fait référence. Les lecteurs du code doivent donc rechercher ses occurrences pour obtenir des indices. Ainsi, si nous nommons bien cette variable, les lecteurs peuvent instantanément savoir ce qu'elle signifie.

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 adéquatement le sens, et ne jamais hésiter à y consacrer 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 d'un module dans votre esprit. Un bon nommage prend du temps, mais à long terme, les avantages l'emportent sur les coûts.

3. Refactoriser les noms

Si vous trouvez un meilleur nom plus tard pendant le développement, n'hésitez pas à le changer immédiatement. Les IDE d'aujourd'hui rendent la refactorisation des noms extrêmement facile.

4. Évitez les mots parasites dans les noms

Par exemple,Manager、Processor、Data、Infoet les synonymes de « Je ne sais pas comment cela s'appelle » sont des mots parasites. Si vous avez besoin d'utiliser ces mots parasites, cela signifie que votre nommage est probablement trop verbeux.

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

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

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

6. Noms de classes

Le nom d'une classe doit être un nom ou un groupe nominal, comme par exempleCustomer、WikiPage、AccountetAddressParserLes superclasses doivent avoir des noms courts et percutants. Les sous-classes doivent avoir des noms plus longs, en utilisant des adjectifs pour décrire en quoi elles diffèrent de leur superclasse, comme par exempleSavingsAccountdérivé de Account.

7. Noms de variables

Les noms de variables doivent aussi être des substantifs. Ils sont pour la plupart dérivés de la classe à laquelle ils font référence. Les variables booléennes doivent être écrites sous forme de prédicat, commeisEmptyetisTerminatedafin qu'elles soient 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 un booléen doivent être préfixées par 'is', comme isPostable(), afin qu'elles soient plus faciles à comprendre dans les instructions if.

9. Taille de la portée et longueur des noms de variables

La longueur d'un nom de variable doit correspondre à sa portée. Si la portée est courte, le nom de variable doit être court également. Inversement, le nom de variable doit être plus long et plus descriptif.

10. Taille de la portée et longueur des noms de méthodes/classes

La longueur des noms de méthodes et de classes doit être inversement proportionnelle à leur portée. Pour les méthodes publiques, des noms plus courts sont préférables, car elles seront appelées de nombreuses fois. Les méthodes privées ne sont appelées qu'à l'intérieur de la classe, donc des noms plus longs peuvent servir de documentation. L'exception à cette règle concerne les noms de classes dérivées. Plus une classe est dérivée, plus on ajoute d'adjectifs avant la classe de base, et plus le nom s'allonge.

11. Un concept, un mot

Choisissez un mot pour un concept abstrait, puis ne le changez pas. Par exemple, pour des méthodes équivalentes dans différentes classes,get()、fetch()andretrieve()changer le mot créerait de la confusion.

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

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

Par exemple, nous pouvons utiliser laadd()méthode 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 la classe pour ajouter un paramètre à une collection, cela causera des problèmes à cause de sémantiques différentes. Il serait préférable de nommer cette nouvelle méthode insert().

13. Utilisez des noms issus du domaine de la solution

15. Ajoutez 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 à quoi ils se réfèrent. Dans certains cas, vous pouvez avoir besoin de préfixer le nom pour ajouter du contexte. Par exemple, supposons que nous ayons quelques variables représentant une adresse :firstName、lastName、street、houseNumber、city、stateetzipSi nous ne regardons que la variable d'état, il est difficile de déduire à quoi elle se réfère. Une meilleure solution consiste à encapsuler ces variables dans une classe Address.

16. N'ajoutez pas de contexte superflu

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

Compte tenu de la puissance des IDE modernes, 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 leurs classes sont transmises à une interface. Donc, si vous devez utiliser un encodage, il est préférable d'encoder les implémentations plutôt que les interfaces.

18. Évitez les informations trompeuses

Ne donnez pas de fausses informations, car cela induirait en erreur les personnes qui lisent le code. Si vous nommez accountList une variable qui contient en réalité un tableau, il est facile pour les gens de tirer une mauvaise conclusion.

19. Utilisez des noms imprononçables

La programmation est une activité sociale. L'utilisation de noms imprononçables ne fera qu'entraver nos discussions.

20. Utilisez des noms faciles à rechercher

L'utilisation de noms courts et génériques rend difficile la recherche d'éléments dans la base de code. Cela a un grand impact sur la manipulation et la refactorisation du code.

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

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