10 conseils pour rédiger un code plus propre et meilleur

Sans aucun doute, la programmation est difficile. C’est une chose Apprendre des langues et étudier algorithmes, mais c’est une toute autre bête qui essaie de coder une application de travail complexe qui ne vous donne pas envie de vous arracher les yeux.

D’une certaine manière, écrire du code propre ressemble beaucoup au dessin, à la cuisine ou à la photographie – cela semble plus facile qu’il ne l’est réellement. Alors pourquoi s’embêter? Eh bien, parce que les avantages en valent la peine:

• Les problèmes deviennent plus faciles à résoudre. Une fois que vous commencez à penser en code propre, votre approche de la résolution de problèmes change. Au lieu de solutions de forçage brutal, vos algorithmes et votre conception de logiciels deviennent plus élégants et intentionnels.
• Moins de temps perdu en maintenance. Le code propre est plus facile à lire et à comprendre, vous passez donc moins de temps à essayer de comprendre ce que font réellement certains segments et plus de temps à corriger, réviser, étendre, etc.
• Les idées sont plus clairement communiquées. Si vous travaillez avec d’autres programmeurs, un code propre réduit la probabilité de malentendus entre vous tous, ce qui signifie également moins de bogues à long terme.

Voici comment VOUS pouvez commencer à écrire du code propre.

1. Utilisez des noms descriptifs

Que sont les variables, les classes et les fonctions? Il existe de nombreuses façons de répondre à cela, mais quand vous y pensez vraiment, ces choses ne sont rien de plus que l’interface entre un programmeur et la logique sous-jacente d’une application.

Ainsi, lorsque vous utilisez des noms peu clairs et non descriptifs pour les variables, les classes et les fonctions, vous obscurcissez essentiellement la logique d’application de tout programmeur qui lit le code, y compris vous-même.

« Je ne suis pas un grand programmeur; Je suis juste un bon programmeur avec de bonnes habitudes. « 
– Kent Beck

Qu’est-ce qu’une variable nommée dxy signifie vraiment? Qui sait. Vous auriez probablement à lire la totalité du bloc de code pour inverser sa signification. D’un autre côté, la signification d’une variable comme distanceBetweenXY est instantanément reconnaissable.

Il en va de même pour les classes et les fonctions. Ne vous contentez pas de CalcTan() quand tu peux partir CalculateTangent() ou CalcTangentAngle() au lieu.

2. Donnez à chaque classe / fonction un objectif

Avez-vous déjà jeté un coup d’œil à l’intérieur d’une fonction qui faisait des centaines voire des milliers de lignes? Si c’est le cas, vous savez à quel point il peut être pénible de parcourir, de comprendre et de modifier. Les commentaires peuvent aider, mais seulement dans une mesure limitée.

« La programmation divise une grande tâche impossible en plusieurs petites tâches possibles. »
– Jazzwant

Le code propre est décomposé en morceaux atomiques. Chaque fonction doit viser à faire une seule chose et chaque classe doit viser à représenter un concept particulier. C’est une simplification bien sûr, mais en cas de doute, plus simple est plus propre.

En pratique, un calcul complexe comme GetCreditScore() peut avoir besoin d’être divisé en plusieurs fonctions d’aide comme GetCreditReports(), ApplyCreditHistoryAge(), et FilterOutstandingMarks().

3. Supprimer le code inutile

Cette mauvaise habitude est celle avec laquelle je lutte toujours de temps en temps. Cela se produit généralement comme ceci: je veux corriger ou optimiser un morceau de code, donc je le commente et je le réécris juste en dessous – et même si cela fonctionne, je garde l’ancien code là juste au cas où.

« Est-il possible que le logiciel ne ressemble à rien d’autre, qu’il soit destiné à être jeté: que le but est de toujours le voir comme une bulle de savon? »
– Alan J. Perlis

Au fil du temps, j’accumule beaucoup de blocs de code commentés qui ne sont plus nécessaires mais encombrent mes fichiers source. Et le plus drôle, c’est que dans de nombreux cas, le code environnant a évolué de sorte que le code commenté ne fonctionnerait pas même s’il était restauré.

Le fait est que cette pratique de commenter le «code de sauvegarde» a été rendue obsolète par le contrôle des sources. Si vous n’utilisez pas quelque chose comme Git ou Mercurial, vous devez commencer à utiliser le contrôle de source immédiatement. Un code plus propre vous attend.

N’oubliez pas, il est également important d’éviter d’écrire du code répétitif, ce que vous pouvez accomplir facilement avec une infrastructure Web. Voici quelques cadres Web qui méritent d’être étudiés en tant que développeur.

4. Lisibilité> Astuce

Trop de programmeurs confondent «code propre» et «code intelligent», comme si le compactage de dix lignes en une seule était en quelque sorte plus propre. Bien sûr, cela prend moins de place à l’écran, mais est-il réellement plus facile à comprendre? Parfois, peut-être. Mais la plupart du temps? Non.

«Tout le monde sait que le débogage est deux fois plus difficile que d’écrire un programme en premier lieu. Donc, si vous êtes aussi intelligent que possible lorsque vous l’écrivez, comment allez-vous le déboguer? « 
– Brian W. Kernighan

Je pense que les programmeurs adorent le code intelligent parce que cela ressemble à un puzzle résolu ou à une énigme. Ils ont trouvé un moyen spécial et unique de mettre en œuvre quelque chose – un «raccourci» si vous voulez – et cela agit presque comme une validation des compétences du programmeur.

Mais pour écrire du code propre, vous devez laisser votre ego à la porte.

Optimisez toujours le code pour la prochaine personne qui va le lire, car il est probable que la prochaine personne sera VOUS et rien de plus honteux que de ne pas pouvoir lire ou comprendre votre propre intelligence.

5. Gardez un style de codage cohérent

Je n’ai rien contre de bons tutoriels de programmation, mais l’un des inconvénients est que les débutants finissent par prendre une grande variété d’habitudes conflictuelles, surtout en ce qui concerne le style de codage.

Je ne suis pas ici pour déclarer qu’un style est meilleur qu’un autre. Si vous voulez des accolades sur leurs propres lignes, allez-y. Si vous souhaitez faire précéder les appels de méthode par des espaces, très bien. Si vous préférez les tabulations aux espaces, ne me laissez pas vous convaincre du contraire.

Mais quoi que vous fassiez, restez cohérent!

Beau, c’est mieux que laid.
Explicite vaut mieux qu’implicite.
Simple, c’est mieux que complexe.
Complexe vaut mieux que compliqué.
L’appartement est meilleur que l’emboîtement.
Clairsemé vaut mieux que dense.
La lisibilité compte.
– Tim Peters, Le zen de Python

Si vous allez utiliser camelCaseNaming pour les variables, ne pas les altérer avec underscore_naming. Si tu utilises GetThisObject() en un seul endroit, n’allez pas avec FetchThatObject() ailleurs. Et si vous mélangez les tabulations et les espaces, vous méritez que votre clavier vous soit retiré.

Décidez de ce que vous allez faire dès le départ et respectez-le de bout en bout. Certains langages, comme Python et C #, ont des guides de style à l’échelle du langage que vous pouvez suivre.

6. Choisissez la bonne architecture

Il existe de nombreux paradigmes et architectures différents que vous pouvez utiliser pour créer vos projets. Notez comment cette astuce consiste à sélectionner droite un pour vos besoins, pas sur la sélection du meilleur un là-bas. Il n’y a pas de «meilleur» ici.

«Sans exigences ni conception, la programmation est l’art d’ajouter des bogues à un fichier texte vide.»
– Louis Srygley

Par exemple, le modèle Model-View-Controller (MVC) est très populaire en ce moment dans le développement Web car il aide à garder votre code organisé et conçu de manière à minimiser les efforts de maintenance.

De même, le modèle Entity-Component-System (ECS) est très populaire en ce moment dans le développement de jeux car il permet de modulariser les données et la logique du jeu d’une manière qui facilite l’entretien, tout en produisant du code plus facile à lire.

7. Maîtriser les idiomes de la langue

L’une des difficultés à maîtriser un nouveau langage de programmation est d’apprendre les nuances qui le séparent de tous les autres langages. Ces nuances peuvent faire la différence entre un code laid et alambiqué et un beau code facile à entretenir.

Prenons Python, Java et JavaScript. Ils sont tous extrêmement différents les uns des autres, à un degré qui nécessite une façon de penser différente selon la langue que vous choisissez d’utiliser.

« Un langage qui n’affecte pas votre façon de penser la programmation ne vaut pas la peine d’être connu. »
– Alan J. Perlis

Alors que Python concerne le code compact et la frappe de canard, Java est plutôt du côté de la verbosité et de l’explicitness. Chaque langue a des idiomes (tels que les compréhensions de liste en Python) qui encouragent une certaine façon de coder. Vous feriez bien de les apprendre.

Il y a aussi des «anti-modèles» dont il faut s’inquiéter, qui sont essentiellement des modèles de conception sous-optimaux qui se traduisent par un code inefficace, peu fiable ou autrement mauvais. Étudiez et désapprenez tous les anti-schémas courants liés à la langue de votre choix.

8. Étudiez le code des maîtres

Si vous voulez écrire du code propre, la meilleure chose que vous puissiez faire est de voir à quoi ressemble le code propre et essayer de comprendre pourquoi c’est ainsi – et il n’y a pas de meilleure façon de le faire qu’en étudiant les fichiers source de l’industrie maîtrise.

De toute évidence, vous ne pouvez pas simplement vous rendre au siège de Microsoft et jeter un œil à leurs projets, mais vous pouvez toujours parcourir des projets open source bien connus. Je ne sais pas par où commencer? Essaie le projets présentés sur Github.

«Tout imbécile peut écrire du code qu’un ordinateur peut comprendre. Les bons programmeurs écrivent du code que les humains peuvent comprendre. »
– Martin Fowler, Refactoring: améliorer la conception du code existant

Après tout, c’est l’une des raisons pour lesquelles les projets open source existent: pour que d’autres puissent en tirer des leçons. Et si vous décidez de contribuer à un tel projet, cela peut accélérer le processus d’apprentissage.

Personnellement, la toute première fois que j’ai vu du code vraiment propre, c’est quand je suis tombé sur le projet Python open source d’un certain amateur. Le code était tellement élégant que j’ai failli quitter la programmation, mais il a fini par m’apprendre beaucoup.

9. Écrivez de bons commentaires

«Écrire de bons commentaires» est le plus ancien conseil du monde de la programmation. En fait, dès que les débutants sont initiés aux commentaires, ils sont à peu près encouragés à commenter aussi souvent qu’ils le peuvent.

Mais on a presque l’impression que nous avons trop poussé dans la direction opposée. Les débutants, en particulier, ont tendance à sur-commenter – en décrivant des choses qui n’ont pas besoin d’être décrites et en oubliant ce qu’est réellement un «bon commentaire».

« Codez toujours comme si le gars qui finit par maintenir votre code sera un psychopathe violent qui sait où vous vivez. »
– John Woods

Voici une bonne règle de base: des commentaires existent pour expliquer POURQUOI un morceau de code existe plutôt que CE QUE fait réellement le code. Si le code est écrit de façon suffisamment claire, il devrait être explicite de ce qu’il fait – le commentaire devrait faire la lumière sur l’intention derrière pourquoi il a été écrit.

Les commentaires peuvent être utiles pour les avertissements (c’est-à-dire « la suppression de cela cassera A, B et C »), mais pour la plupart, ils devraient découvrir des choses qui ne peuvent pas être immédiatement glanées dans le code (c’est-à-dire « utiliser ce paramètre parce que X, Y, et Z ”).

10. Refactor, Refactor, Refactor

Tout comme l’édition fait partie du processus d’écriture, la refactorisation fait partie du processus de codage. Une aversion pour le refactoring est le moyen le plus rapide de se retrouver avec du code non maintenable, donc à bien des égards, c’est en fait le conseil le plus important à considérer.

En bref, le refactoring n’est qu’un terme de fantaisie pour nettoyer le code sans affecter son comportement réel.

«Chaque fois que je dois réfléchir pour comprendre ce que fait le code, je me demande si je peux refactoriser le code pour rendre cette compréhension plus immédiatement apparente.»
– Martin Fowler, Refactoring: améliorer la conception du code existant

Un peu de sagesse qui m’a marqué est le dicton: «Ne commentez pas le mauvais code. Réécris-le.  » Comme l’explique Fowler dans la citation ci-dessus, si le code vous semble assez confus pour que vous deviez le commenter, vous devrez peut-être le refactoriser.

De plus, lorsque vous modifiez des morceaux de code ici et là tout au long de votre projet, laissez toujours le code dans un meilleur état que lorsque vous l’avez trouvé. Cela peut sembler une nuisance pour le moment, mais cela sera payant à long terme (et peut même éviter l’épuisement mental).

Il y a toujours quelque chose de nouveau à apprendre

Un programmeur qui apprend à écrire du code propre s’apparente à un romancier qui apprend à écrire de la prose propre: il n’y a pas une bonne façon de le faire en soi, mais il y a beaucoup de mauvaises façons de le faire, et cela prendra années à maîtriser.

Certaines personnes n’ont pas ce qu’il faut et finissent par quitter la programmation pour de bon – et c’est très bien car il y a beaucoup d’autres emplois techniques qui n’impliquent pas de codage. Mais pour tout le monde, le code propre est quelque chose qui vaut vraiment la peine d’être recherché, même si cela prend le reste de votre vie pour y arriver.