Comment écrire un code propre en suivant ces règles.

Tu as déjà l'habitude d'écrire du code ? Tu es vraiment un bon développeur ? Alors tu devrais vérifier si tu respectes ces règles dans ton code.

C'est quoi un code propre ?

Le code est propre s’il peut être compris facilement - par tous les membres de l’équipe. Un code propre peut être lu et amélioré par un développeur autre que son auteur d’origine. La compréhensibilité s’accompagne de lisibilité, d’évolutivité, d’extensibilité et de maintenabilité.

Robert C. Martin

Robert Cecil Martin est un ingénieur logiciel et auteur américain. Il est co-auteur du Manifeste Agile. Il dirige maintenant la société de conseil Uncle Bob Consulting LLC et le site web Clean Coders, qui héberge des vidéos basées sur son expérience et ses publications.

Nous allons donc découvrir une synthèse de son livre "Coder proprement.".

Règles générales

1. Suivez les conventions standards.

2. Restez simple. Plus simple est toujours mieux. Réduisez la complexité autant que possible.

3. Règle de boy-scout. Laissez le camping plus propre que vous ne l’avez trouvé.

4. Trouvez toujours la cause première. Recherchez toujours la cause première d’un problème.

 

Règles de conception

1. Conservez les données configurables à des niveaux élevés.

2. Préférez le polymorphisme à if/else ou switch/case.

3. Séparé le Code multithread.

4. Éviter la surcharge de configuration.

5. Utilisez l’injection de dépendance.

6. Suivez la loi de Déméter : une classe ne doit connaître que ses dépendances directes.

 

Conseils de compréhension

1. Être cohérent. Si vous faites quelque chose d’une certaine manière, faites toutes les choses similaires de la même manière.

2. Utilisez des variables explicatives.

3. Encapsuler les conditions aux limites. Les conditions aux limites sont difficiles à suivre. Mettez leur traitement en un seul endroit.

4. Préférez les objets de valeur dédiés au type primitif.

5. Évitez les dépendances logiques. N’écrivez pas de méthodes qui fonctionnent correctement en fonction de quelque chose d’autre dans la même classe.

6. Évitez les conditionnels négatifs.

 

Règles de nomenclature

1. Choisissez des noms descriptifs et sans ambiguïté.

2. Faites une distinction significative.

3. Utilisez des noms prononçables.

4. Utilisez des noms interrogeables.

5. Remplacez les nombres magiques par des constantes nommées.

6. Évitez les encodages. N’ajoutez pas de préfixes ou de l’information du type.

 

Règles de fonctions

1. Petit.

2. Fais une chose.

3. Utilisez des noms descriptifs.

4. Préférez moins d’arguments.

5. Ne pas avoir d’effets secondaires.

6. N’utilisez pas d’arguments avec indicateurs. Méthode fractionnée en plusieurs méthodes indépendantes pouvant être appelées depuis le client sans indicateur.

 

Règles de commentaires

1. Essayez toujours de vous expliquer dans le code.

2. Ne soyez pas redondant.

3. N’ajoutez pas de bruits inutiles.

4. N’utilisez pas de commentaires avec accolade fermante.

5. Ne commentez pas le code. Supprimez simplement.

6. Utiliser comme explication de l’intention.

7. Utiliser comme clarification du code.

8. Utiliser comme avertissement des conséquences.

 

Structure du code source

1. Séparez les concepts verticalement.

2. Le code associé doit apparaître verticalement dense.

3. Déclarez les variables proches de leur utilisation.

4. Les fonctions dépendantes doivent être proches.

5. Des fonctions similaires doivent être proches.

6. Placer les fonctions vers le bas.

7. Gardez les lignes courtes.

8. N’utilisez pas l’alignement horizontal.

9. Utilisez un espace blanc pour associer des éléments liés et dissocier des éléments faiblement liés.

10. Ne cassez pas l’indentation.

 

Objets et structures de données

1. Masquer la structure interne.

2. Préférez les structures de données.

3. Évitez les structures hybrides (moitié objet et moitié données).

4. Devrait être petit.

5. Fais une chose.

6. Petit nombre de variables d’instance.

7. La classe de base ne doit rien savoir de leurs dérivés.

8. Mieux vaut avoir de nombreuses fonctions que de passer du code dans une fonction pour sélectionner un comportement.

9. Préférez les méthodes non-statiques aux méthodes statiques.

 

Test

1. Une assertion par test.

2. Lisible.

3. Vite.

4. Indépendant.

5. Répétable.

 

Odeurs du code

1. Rigidité. Le logiciel est difficile à changer. Un petit changement provoque une cascade de changements ultérieurs.

2. Fragilité. Le logiciel tombe en panne à de nombreux endroits en raison d’un seul changement.

3. 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.

4. Complexité inutile.

5. Répétition inutile.

6. Opacité. Le code est difficile à comprendre.

 

Donne ton point de vue en commentaire et partage avec les autres.