Bonjour, Habr! Je vous présente la traduction de l'article "Les noms longs sont longs" de Bob Nystrom.
L'une des choses intelligentes que Google fait est un examen strict du code. Chaque modification, avant que vous ne puissiez vous rendre à la branche principale, est considérée dans au moins deux directions. Tout d'abord, un membre de l'équipe effectue une vérification de routine pour s'assurer que le code fait ce qu'il devrait.
Mais alors la deuxième étape se produit, lorsque la lisibilité du code est vérifiée. Cela garantit que d'autres développeurs pourront à l'avenir prendre en charge ce code. Ce code est-il facile à comprendre et à maintenir? Ce code correspond-il au style et aux idiomes de la langue? Le code est-il bien documenté?
L'utilisation du langage Dart sur Google gagne progressivement du terrain, et j'ai beaucoup traité avec une telle révision de code. Pour un développeur de langage, c'est un processus très excitant. J'ai un aperçu direct de la façon dont les gens utilisent Dart, ce qui est vraiment utile pour son développement. J'ai une idée plus claire des erreurs courantes et des fonctions les plus utilisées. Je me sens comme un ethnographe, un journal sur la vie des indigènes.
Mais, en tout cas, ce n'est pas le cas. Merde, ce n'est même pas des fléchettes. Je veux parler de ce que je vois dans de nombreux codes et de ce qui me rend fou: des noms trop longs .
Oui, les noms peuvent être trop courts. À l'époque où C exigeait que seuls les identifiants externes soient uniques jusqu'aux six premiers caractères; lorsque l'auto-complétion n'a pas encore été inventée; quand chaque frappe était comme monter dans la neige - c'était un problème. Je suis heureux que nous vivions maintenant dans une utopie futuriste, où les pets de clavier comme p , idxcrpm et x3 sont rares.
Mais le pendule a basculé trop loin dans l'autre sens. Nous n'avons pas besoin d'être Hemingway, nous n'avons pas non plus besoin d'être Tennessee Williams. Des noms trop longs nuisent également à la clarté du code dans lequel ils sont utilisés. Les noms de variable très longs éclipsent les opérations que vous effectuez sur eux. Le code devient difficile à analyser visuellement. Pour répondre aux exigences de largeur de code, des sauts de ligne supplémentaires apparaissent qui interrompent le flux logique de code. Les noms de méthode longs masquent leurs listes d'arguments tout aussi importantes. Les variables longues sont gênantes par la réutilisation, ce qui conduit à étirer les chaînes de méthodes ou les cascades.
J'ai vu des noms de variables de plus de 60 caractères. Vous pouvez y mettre un haïku ou un koan (et éclairer probablement le lecteur plus que le nom que vous choisissez). Mais n'ayez crainte, je suis là pour vous aider.
Choisir un bon nom
Tout nom dans la programmation a deux objectifs:
- Le nom doit être clair : vous devez savoir à quoi il fait référence.
- Le nom doit être exact : vous devez savoir à quoi il ne s'applique pas.
Une fois que le nom a atteint ces objectifs, tout personnage supplémentaire est mort. Voici quelques directives que j'utilise lorsque je nomme des choses dans mon code:
1. Évitez les mots qui sont explicitement spécifiés dans une variable ou un type de paramètre
Si votre langue possède un système de type statique, les utilisateurs connaissent généralement le type de la variable. En règle générale, les méthodes sont assez courtes, donc même en regardant une variable locale où le type ne peut pas être supposé immédiatement, ou lors d'une révision de code, ou dans un endroit où l'analyse de code statique ne peut pas entrer - nécessite rarement un peu plus que de regarder quelques lignes ci-dessus pour déterminer le type de variable.
Compte tenu de cela, il n'est pas nécessaire d'indiquer le type dans le nom de la variable. Nous venons d'abandonner la notation hongroise . Lâchez prise et oubliez :
En particulier pour les collections, il est presque toujours préférable d'utiliser un nom pluriel décrivant le contenu qu'un nom singulier décrivant une collection . Si le lecteur se soucie davantage de ce qui se trouve dans la collection, le titre devrait refléter cela.
Cela s'applique également aux noms de méthode. Le nom de la méthode n'a pas besoin de décrire ses paramètres ou leurs types - la liste des paramètres le fera pour vous.
Cela se traduit par une meilleure lecture des appels:
mergeTableCells(tableCells); sortEventsUsingComparator(events, comparator);
Est-ce juste moi ou y a-t-il un écho-écho ici?
2. Évitez les mots qui ne désambiguïsent pas le nom
Certaines personnes ont tendance à mettre tout ce qu'elles savent sur quelque chose dans le nom d'une variable. N'oubliez pas que le nom est un identifiant : il indique l'endroit où il est défini. Ce n'est pas un catalogue exhaustif de tout ce que le lecteur peut vouloir savoir sur l'objet. La définition le rendra meilleur. Le nom ne fera que le diriger là-bas.
Quand je vois le nom comme recentlyUpdatedAnnualSalesBid , je me demande:
- Y a-t-il des commandes client mises à jour qui ne sont pas les plus récentes?
- Y a-t-il des demandes de ventes annuelles récentes qui n'ont pas été mises à jour?
- Existe-t-il des applications non commerciales annuelles récemment mises à jour?
- Existe-t-il des données de ventes annuelles récemment mises à jour qui ne sont pas des offres?
Si la réponse est «non» à au moins une de ces questions, cela indique généralement un mot supplémentaire dans le nom.
Bien sûr, vous pourriez bien aller trop loin. Raccourcir le premier exemple pour bid peut être trop vague. Mais en cas de doute, laissez-le comme ça. Vous pouvez toujours ajouter une classification supplémentaire ultérieurement si le nom est la cause du conflit ou est inexact. Cependant, il est peu probable que vous reveniez plus tard pour couper tout cet excès de graisse.
3. Évitez les mots qui sont clairs d'après le contexte.
Je peux utiliser le mot «je» dans ce paragraphe parce que vous savez que ce texte est de Bob Nystrom. Je n'ai pas besoin de répéter constamment "Bob Nystrom" ici (malgré la tentation de Bob Nystrom de renforcer Bob Nystrom de cette façon). Le code fonctionne exactement de la même manière. Une méthode ou un champ se produit dans le contexte d'une classe. Une variable se produit dans le contexte d'une méthode. Prenez ce contexte pour acquis et ne le répétez pas.
En pratique, cela signifie que plus le nom est ancré profondément, plus le contexte est environnant. En conséquence, il s'avère que ce nom sera plus court. En conséquence, vous pouvez voir un modèle: les identificateurs qui se trouvent dans une zone plus étroite ont des noms plus courts.
4. Évitez les mots qui ne veulent rien dire.
Je vois souvent cette erreur dans l'industrie du jeu. Certains développeurs succombent à la tentation et gonflent les noms de leurs variables, ajoutant des mots de «business sérieux». Ils croient que cela rend leur code plus important et, par conséquent, les rend plus importants.
Dans la plupart des cas, ces mots ne contiennent aucune information significative pour le développeur. En règle générale, les soupçons portent sur des mots tels que: data , state , amount , value , manager , engine , object , entity et instance .
Un bon nom dépeint une image dans l'esprit du lecteur. Appelant quoi que ce soit un «gestionnaire», nous ne donnons au lecteur aucune information sur ce que cet objet doit faire. Fait-il un calcul d'évaluation des performances? Nomme une promotion à leurs employés?
Demandez-vous: "Est-ce que ce nom aura la même signification si je retire ce mot?" Si oui, alors le mot n'a pas d'importance - sortez de l'île.
Application du manuel aux ... gaufres
Pour vous donner une idée du fonctionnement de ces règles dans la pratique, voici un exemple qui les viole toutes. Cet exemple artificiel est très similaire au code réel, qui me vient souvent à l'esprit lors de la révision du code.
class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffleWithStrawberryList( List<Strawberry> strawberryList) { ... } }
Grâce au type de paramètre, nous savons que la méthode accepte une liste de fraises (# 1). Supprimons ces informations d'un nom:
class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffle( List<Strawberry> strawberries) { ... } }
S'il n'y a pas de gaufres belges insipides ou de gaufres d'autres nationalités dans le programme, alors nous pouvons éliminer en toute sécurité tous les adjectifs (# 2):
class WaffleObject { void garnishWaffle(List<Strawberry> strawberries) { ... } }
Cette méthode est à l'intérieur de WaffleObject , donc d'après le contexte, nous savons exactement ce qu'elle va décorer (# 3):
class WaffleObject { void garnish(List<Strawberry> strawberries) { ... } }
C'est évidemment un objet. Tout est un objet en programmation orientée objet (# 4):
class Waffle { void garnish(List<Strawberry> strawberries) { ... } }
Maintenant beaucoup mieux.
Je pense que ce sont des recommandations assez simples. Vous avez le droit de penser qu'il est inutile de s'inquiéter de telles bagatelles. Mais je crois que le nommage est l'une des tâches les plus fondamentales que nous effectuons lors de la programmation. Les noms sont la structure que nous imposons à la mer informe de bits, qui est l'ordinateur.