Apprendre sans réfléchir est un travail perdu ; penser sans apprendre est périlleux.
Les ninjas programmeurs du passé utilisaient ces astuces pour aiguiser l’esprit des responsables de la maintenance du code.
Les gourous de la révision de code les recherchent dans les tâches de test.
Les développeurs novices les utilisent parfois encore mieux que les programmeurs ninjas.
Lisez-les attentivement et découvrez qui vous êtes : un ninja, un novice ou peut-être un réviseur de code ?
Ironie détectée
Beaucoup essaient de suivre les chemins des ninjas. Rares sont ceux qui réussissent.
Rendez le code aussi court que possible. Montrez à quel point vous êtes intelligent.
Laissez-vous guider par les fonctionnalités subtiles du langage.
Par exemple, jetez un œil à cet opérateur ternaire '?' :
// extrait d'une bibliothèque javascript bien connue je = je ? je < 0 ? Math.max(0, len + i) : i : 0;
Cool, non ? Si vous écrivez comme ça, un développeur qui tombe sur cette ligne et essaie de comprendre quelle est la valeur de i va passer un bon moment. Alors venez à vous, cherchant une réponse.
Dites-leur que plus court est toujours mieux. Initiez-les aux sentiers du ninja.
Le Tao se cache dans le silence. Seul le Tao est bien commencé et bien achevé.
Une autre façon de coder plus court consiste à utiliser partout des noms de variables à une seule lettre. Comme a , b ou c .
Une courte variable disparaît dans le code comme un vrai ninja dans la forêt. Personne ne pourra le trouver en utilisant la « recherche » de l’éditeur. Et même si quelqu'un le fait, il ne sera pas capable de « déchiffrer » ce que signifie le nom a ou b .
…Mais il y a une exception. Un vrai ninja n'utilisera jamais i comme compteur dans une boucle "for" . N'importe où, mais pas ici. Regardez autour de vous, il y a beaucoup plus de lettres exotiques. Par exemple, x ou y .
Une variable exotique comme compteur de boucles est particulièrement intéressante si le corps de la boucle prend 1 à 2 pages (allongez-le si vous le pouvez). Ensuite, si quelqu'un regarde au plus profond de la boucle, il ne sera pas en mesure de comprendre rapidement que la variable nommée x est le compteur de boucle.
Si les règles de l'équipe interdisent l'utilisation de noms vagues et à une seule lettre, raccourcissez-les, faites des abréviations.
Comme ça:
list → lst .
userAgent → ua .
browser → brsr .
…etc
Seul celui qui a une très bonne intuition sera capable de comprendre de tels noms. Essayez de tout raccourcir. Seule une personne digne devrait être capable de soutenir le développement de votre code.
La grande place est sans coin
Le grand vaisseau est terminé pour la dernière fois,
La grande note est un son raréfié,
La grande image n'a pas de forme.
Lorsque vous choisissez un nom, essayez d'utiliser le mot le plus abstrait. Comme obj , data , value , item , elem et ainsi de suite.
Le nom idéal pour une variable est data . Utilisez-le partout où vous le pouvez. En effet, chaque variable contient des données , n'est-ce pas ?
…Mais que faire si data sont déjà récupérées ? Essayez value , c'est aussi universel. Après tout, une variable finit par obtenir une valeur .
Nommez une variable par son type : str , num …
Essayez-les. Un jeune initié peut se demander : de tels noms sont-ils vraiment utiles pour un ninja ? En effet, ils le sont !
Bien sûr, le nom de la variable signifie toujours quelque chose. Il indique ce qu'il y a à l'intérieur de la variable : une chaîne, un nombre ou autre chose. Mais lorsqu’un étranger essaie de comprendre le code, il sera surpris de constater qu’il n’y a en réalité aucune information ! Et ne parviendra finalement pas à modifier votre code bien pensé.
Le type de valeur est facile à découvrir par débogage. Mais quelle est la signification de la variable ? Quelle chaîne/numéro stocke-t-il ?
Il n’y a tout simplement aucun moyen de comprendre sans une bonne méditation !
…Mais et s’il n’y avait plus de tels noms ? Ajoutez simplement un numéro : data1, item2, elem5 …
Seul un programmeur vraiment attentif devrait être capable de comprendre votre code. Mais comment vérifier cela ?
Une des façons : utilisez des noms de variables similaires, comme date et data .
Mélangez-les là où vous le pouvez.
Une lecture rapide d'un tel code devient impossible. Et quand il y a une faute de frappe… Ummm… On reste coincé longtemps, il est temps de boire du thé.
Le Tao qu’on peut raconter n’est pas le Tao éternel. Le nom qui peut être nommé n’est pas le nom éternel.
Utiliser des noms similaires pour les mêmes choses rend la vie plus intéressante et montre votre créativité au public.
Par exemple, considérons les préfixes de fonction. Si une fonction affiche un message à l'écran, démarrez-la avec display… , comme displayMessage . Et puis si une autre fonction affiche à l'écran autre chose, comme un nom d'utilisateur, démarrez-la avec show… (comme showName ).
Insinuez qu'il existe une différence subtile entre de telles fonctions, alors qu'il n'y en a pas.
Faites un pacte avec les autres ninjas de l'équipe : si John commence à "afficher" des fonctions avec display... dans son code, alors Peter pourrait utiliser render.. , et Ann – paint... . Notez à quel point le code est devenu plus intéressant et diversifié.
…Et maintenant le tour du chapeau !
Pour deux fonctions présentant des différences importantes – utilisez le même préfixe !
Par exemple, la fonction printPage(page) utilisera une imprimante. Et la fonction printText(text) mettra le texte à l'écran. Laissez un lecteur inconnu réfléchir à la fonction printMessage du même nom : « Où met-il le message ? Sur une imprimante ou sur l'écran ? Pour le faire vraiment briller, printMessage(message) devrait l'afficher dans la nouvelle fenêtre !
Une fois le tout divisé, les parties
besoin de noms.
Il y a déjà suffisamment de noms.
Il faut savoir s'arrêter.
Ajoutez une nouvelle variable uniquement lorsque cela est absolument nécessaire.
Réutilisez plutôt les noms existants. Écrivez-y simplement de nouvelles valeurs.
Dans une fonction, essayez d'utiliser uniquement les variables passées en paramètres.
Cela rendrait très difficile d'identifier ce qu'il y a exactement dans la variable maintenant . Et aussi d'où ça vient. Le but est de développer l'intuition et la mémoire d'une personne lisant le code. Une personne ayant une faible intuition devrait analyser le code ligne par ligne et suivre les modifications dans chaque branche du code.
Une variante avancée de l'approche consiste à remplacer secrètement (!) la valeur par quelque chose de similaire au milieu d'une boucle ou d'une fonction.
Par exemple:
fonction ninjaFonction(elem) {
// 20 lignes de code travaillant avec elem
elem = clone(elem);
// 20 lignes supplémentaires, travaillant maintenant avec le clone de l'elem !
} Un collègue programmeur qui souhaite travailler avec elem dans la seconde moitié de la fonction sera surpris… Ce n'est que pendant le débogage, après avoir examiné le code, qu'il découvrira qu'il travaille avec un clone !
Vu régulièrement dans le code. Mortellement efficace même contre un ninja expérimenté.
Mettez les traits de soulignement _ et __ avant les noms de variables. Comme _name ou __value . Ce serait formidable si seulement vous connaissiez leur signification. Ou, mieux, ajoutez-les juste pour le plaisir, sans aucune signification particulière. Ou des significations différentes selon les endroits.
Vous tuez deux lapins d’un seul coup. Premièrement, le code devient plus long et moins lisible, et deuxièmement, un collègue développeur peut passer beaucoup de temps à essayer de comprendre la signification des traits de soulignement.
Un ninja intelligent place des traits de soulignement à un endroit du code et les évite à d'autres endroits. Cela rend le code encore plus fragile et augmente la probabilité de futures erreurs.
Faites voir à tout le monde à quel point vos entités sont magnifiques ! Des noms comme superElement , megaFrame et niceItem éclaireront certainement le lecteur.
En effet, d'une part, quelque chose est écrit : super.. , mega.. , nice.. Mais de l'autre côté – cela n'apporte aucun détail. Un lecteur peut décider de rechercher un sens caché et de méditer pendant une heure ou deux de son temps de travail rémunéré.
Quand on est dans la lumière, on ne voit rien dans l'obscurité.
Dans l’obscurité, on peut tout voir à la lumière.
Utilisez les mêmes noms pour les variables à l’intérieur et à l’extérieur d’une fonction. Aussi simple. Aucun effort pour inventer de nouveaux noms.
laissez l'utilisateur = AuthenticateUser();
fonction rendu() {
laissez l'utilisateur = une autreValue();
...
...beaucoup de lignes...
...
... // <-- un programmeur veut travailler avec l'utilisateur ici et...
...
} Un programmeur qui saute à l'intérieur du render ne remarquera probablement pas qu'il y a un user local qui observe l'utilisateur extérieur.
Ensuite, ils essaieront de travailler avec user en supposant qu'il s'agit de la variable externe, le résultat authenticateUser() … Le piège est déclenché ! Bonjour, débogueur…
Il y a des fonctions qui semblent ne rien changer. Comme isReady() , checkPermission() , findTags() … Ils sont supposés effectuer des calculs, rechercher et renvoyer les données, sans rien changer en dehors d'elles. Autrement dit, sans « effets secondaires ».
Une très belle astuce consiste à leur ajouter une action « utile », en plus de la tâche principale.
Une expression de surprise hébétée sur le visage de votre collègue lorsqu'il voit une fonction nommée is.. , check.. ou find... changer quelque chose - élargira certainement les limites de votre raison.
Une autre façon de surprendre est de renvoyer un résultat non standard.
Montrez votre pensée originale ! Laissez l'appel de checkPermission renvoyer non pas true/false , mais un objet complexe avec les résultats de la vérification.
Les développeurs qui essaient d'écrire if (checkPermission(..)) , se demanderont pourquoi cela ne fonctionne pas. Dites-leur : « Lisez la documentation ! ». Et donnez cet article.
Le grand Tao coule partout,
à gauche comme à droite.
Ne limitez pas la fonction par ce qui est écrit dans son nom. Soyez plus large.
Par exemple, une fonction validateEmail(email) pourrait (en plus de vérifier l'exactitude de l'e-mail) afficher un message d'erreur et demander de ressaisir l'e-mail.
Les actions supplémentaires ne doivent pas être évidentes à partir du nom de la fonction. Un vrai codeur ninja les rendra également moins évidents dans le code.
La réunion de plusieurs actions en une seule protège votre code de la réutilisation.
Imaginez, un autre développeur souhaite uniquement vérifier le courrier électronique et n'afficher aucun message. Votre fonction validateEmail(email) qui fait les deux ne leur conviendra pas. Ainsi, ils ne interrompront pas votre méditation en vous posant des questions à ce sujet.
Tous les « conseils » ci-dessus sont issus du vrai code… Parfois, rédigés par des développeurs expérimentés. Peut-être même plus expérimenté que vous ;)
Suivez-en quelques-uns et votre code deviendra plein de surprises.
Suivez-en plusieurs et votre code deviendra vraiment le vôtre, personne ne voudrait le changer.
Suivez tout et votre code deviendra une leçon précieuse pour les jeunes développeurs en quête d’illumination.