Ecrire pour être examiné
Meilleure pratique 4 - Le code doit être rédigé pour être révisé
Lors de l'écriture de votre code logiciel, gardez à l'esprit que quelqu'un va réviser votre code et que vous devrez faire face à des critiques sur un ou plusieurs des points suivants, mais sans s'y limiter:
- Mauvais codage
- Non conforme à la norme
- Ne pas garder à l'esprit les performances
- L'historique, l'indentation, les commentaires ne sont pas appropriés.
- La lisibilité est médiocre
- Les fichiers ouverts ne sont pas fermés
- La mémoire allouée n'a pas été libérée
- Trop de variables globales.
- Trop de codage en dur.
- Mauvaise gestion des erreurs.
- Pas de modularité.
- Code répété.
Gardez tous les points mentionnés ci-dessus à l'esprit pendant le codage et arrêtez-les avant qu'ils ne sautent dans votre code source. Une fois que vous avez terminé votre codage, effectuez une auto-évaluation au moins une fois. Je suis sûr qu'une auto-évaluation vous aiderait à éliminer vous-même 90% des problèmes.
Une fois que vous avez terminé votre codage et votre auto-évaluation, demandez à votre pair de réviser le code. Je recommanderais fortement d'accepter les commentaires de révision avec plaisir et je devrais être reconnaissant à vos réviseurs de code pour les commentaires. En même temps, il n'est jamais bon de critiquer un code source écrit par quelqu'un d'autre. Si vous ne l'avez jamais fait, essayez-le une fois et vérifiez l'expression du codeur.
Acceptez les critiques mais ne critiquez pas
Un code source mal écrit vous apprend à écrire un bon code source à condition de le prendre positivement et d'en tirer une leçon.
![](https://assets.edu.lat/developers_best_practices/images/bug_free_code.jpg)
Votre objectif devrait être d'arrêter les bogues en premier lieu et de créer un code SANS BUG. Pensez comme un testeur, afin que vous ayez un défi pour les testeurs.