Le code est propre s'il peut être compris facilement par tous les membres de l'équipe. Le code propre peut être lu et amélioré par un développeur autre que son auteur d'origine. Avec la compréhensibilité vient la lisibilité, la capacité de changement, l'extensibilité et la maintenabilité.
- Suivez les conventions standard.
- Reste simple bête. Plus simple, c'est toujours mieux. Réduisez la complexité autant que possible.
- Règle des scouts. Laissez le camping plus propre que vous l'avez trouvé.
- Toujours trouver la cause première. Recherchez toujours la cause fondamentale d'un problème.
- Conservez les données configurables à des niveaux élevés.
- Préférer le polymorphisme à if / else ou switch / case.
- Séparez le code multi-thread.
- Empêcher la configurabilité excessive.
- Utiliser l'injection de dépendance.
- Suivez la loi de Déméter. Une classe ne devrait connaître que ses dépendances directes.
- Soyez cohérent. Si vous faites quelque chose d'une certaine manière, faites toutes les choses similaires de la même manière.
- Utiliser des variables explicatives.
- Encapsuler les conditions aux limites. Les conditions aux limites sont difficiles à suivre. Mettez le traitement pour eux en un seul endroit.
- Préférer les objets de valeur dédiés au type primitif.
- Évitez la dépendance logique. N'écrivez pas de méthodes qui fonctionnent correctement en fonction de quelque chose d'autre dans la même classe.
- Évitez les conditionnels négatifs.
- Choisissez des noms descriptifs et non ambigus.
- Faites une distinction significative.
- Utilisez des noms prononcés.
- Utilisez des noms consultables.
- Remplacez les nombres magiques par des constantes nommées.
- Évitez les encodages. N'ajoutez pas de préfixes ou tapez des informations.
- petite.
- Font une chose.
- Utilisez des noms descriptifs.
- Préférez moins d’arguments.
- Ne pas avoir d'effets secondaires.
- N'utilisez pas de flag. Séparer la méthode en plusieurs méthodes indépendantes qui peuvent être appelées à partir du client sans le flag.
- Essayez toujours de vous expliquer dans le code et non dans les commentaires.
- Ne soyez pas redondant.
- N'ajoutez pas de bruit au fichier
- Un commentaire a sa propre ligne.
- Ne pas commenter le code. Il suffit de supprimer.
- Utiliser comme explication d'intention.
- Utiliser comme clarification du code.
- Utilisez comme avertissement des conséquences.
- Séparer les concepts verticalement.
- Le code associé doit apparaître verticalement proche.
- Déclarez les variables proches de leur utilisation.
- Les fonctions dépendantes doivent être proches.
- Les fonctions similaires doivent être proches.
- Placez les fonctions vers le bas.
- Gardez les lignes courtes.
- N'utilisez pas l'alignement horizontal.
- Utilisez des espaces blancs pour associer des choses apparentées et dissociez-les faiblement liées.
- Ne pas casser l'indentation.
- Cacher la structure interne.
- Préférer les structures de données.
- Évitez les structures hybrides (demi-objet et demi-données).
- Devrait être petit.
- Font une chose.
- Petit nombre de variables d'instance.
- La classe de base ne devrait rien savoir de leurs dérivés.
- Mieux vaut avoir plusieurs fonctions que de passer du code dans une fonction pour sélectionner un comportement.
- Préférer les méthodes non statiques aux méthodes statiques.
- Une affirmation par test.
- lisible.
- rapide.
- Indépendant
- Répétable
- Rigidité. Le logiciel est difficile à changer. Un petit changement entraîne une cascade de modifications ultérieures.
- Fragilité. Le logiciel se brise dans de nombreux endroits en raison d'un seul changement.
- Immobilité. Vous ne pouvez pas réutiliser des parties du code dans d'autres projets en raison des risques impliqués et des efforts importants.
- Complexité inutile.
- répétition inutile.
- Opacité. Le code est difficile à comprendre.