La revue de code doit être un aspect obligatoire de l’évolution d’une base logicielle en évolution. La lecture du code doit être au centre du processus d’assurance qualité entre les membres d’une équipe de développement.
Avec le temps, j’ai appris à apprécier la révision de code écrit par d’autres développeurs. Il s’agit d’une d’une excellente opportunité pour apprendre de nouvelles techniques de programmation et surtout comprendre le schéma de pensée de vos camarades.
Pour réviser du code, il faut avoir une idée de ce qu’il faut passer en revue. Souvent, j’aime bien prendre un changeset et en faire une première lecture rapide. Lors de cette première étape, je prends des notes. Des fois, il y a des éléments que je souhaite revoir plus en détail. Cette revue rapide me permet d’identifier des aspects visuels qui vont attirer mon attention pour une deuxième étape.
Lors d’une lecture subséquente, c’est là que je vais regarder un peu plus en détail les aspects syntaxiques et algorithmiques de la solution proposée. Certaines questions à poser à cette étape:
- La solution a-t-elle du sens?
- Y a-t-il des éléments de code pouvant être simplifiés? (ex.: conditions if, structures décisionnelles imbriquées dans les boucles, etc.)
La première question est vraiment une question de feeling. Je crois, cependant, qu’elle est très importante. Si elle ne fait pas de sens maintenant, elle n’en fera pas plus dans six mois ou, même, un an.
Lorsqu’il est temps d’avoir du sens à propos de solutions programmées, il y a quelques exemples qui me viennent en tête.
Nommer les conditions
Qu’une condition dans un if ou même dans une méthode LINQ, lorsqu’elle devient un peu trop compliquée, il est bien de considérer les actions suivantes:
- Fractionner la condition en une série de plus petite
- Extraire la condition en question dans une méthode afin de lui donner un nom plus concret.
Le principal contre-argument de cette façon de faire est que cela rend le code plus long. Vrai. Cependant, si la condition est bien nommée et fait bien son travail, je n’aurai pas besoin d’aller lire et relire à plusieurs reprises ce qu’elle est supposée valider. Son nom devrait suffire.
Une méthode vaut dix commentaires.
Préférer les méthodes LINQ chaînées
Il y a deux façons de faire des opérations LINQ avec C#. La blague serait de dire la bonne ou la mauvaise. Je vais m’abstenir, cette fois-ci
La syntaxe « requête »
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| var names = from item in collection | |
| where item.Name == "Fred" | |
| order by item.Age | |
| select item.Name; |
La syntaxe « méthode »
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| var names = collection | |
| .Where(item => item.Name == "Fred") | |
| .OrderBy(item => item.Age) | |
| .Select(item => item.Name) |
Généralement, j’essaie de m’éloigner de la syntaxe requête. Je trouve qu’au niveau du style, elle s’éloigne de la syntaxe générale du C#. Qu’elle ressemble trop au SQL, en fait, et ça contribue à diminuer l’homogénéité d’une classe lorsqu’elle est présente.
Éviter les multiples classes dans un seul fichier C#
Cette règle est simple. Il n’y a pas de raison valide pour faire en sorte d’imbriquer plusieurs classes dans le même fichier .cs. Lorsque je regarde la structure d’une solution Visual Studio, je veux être en mesure de voir la structure et l’organisation des différents fichiers d’un seul coup.
Alors, la règle est simple. Pas de mauvaises surprises. Un fichier .cs est égal à une classe concrète. La même chose s’applique aux classes utilitaires ou même les interfaces. Chacun dans son coin!
Billets de code
Ce n’est pas la première fois que j’écris un billet au sujet du développement logiciel. Si vous avez apprécié ce billet, vous apprécierez probablement ceux-ci aussi. Bonne lecture!
- Réflexion : Mes critères pour du code de qualité
- Une revue de code autour de l’utilisation d’une boucle for
- Il était une fois des programmeurs voulant nommer une classe
- Doit-on placer les directives ‘using’ en haut ou en bas du namespace?
- Six refactorings pour améliorer la lisibilité de votre code
- Toi, que fais-tu de tes dépendances?
French Coding 
Lorsque je fais du LINQ, j’essaie également de rester loin de la syntaxe de type « requête ».