Tu peux déroger à ces commandements si tu les comprends bien et si le code résultant est plus lisible et plus élégant… mais réfléchis bien!

1. Tu éviteras les variables globales

Tu n'utiliseras pas de variable globale et les méthodes ne modifieront pas d'état global.

2. Tu mettras un entête dans chaque fichier source

Tu commenceras tous les fichiers sources par un commentaire avec un copyright, un titre, le ou les auteurs, la date de création et la date de dernière modification.

3. Tu choisiras les identificateurs avec grand soin

Tu nommeras les identificateurs avec soin. Tu utiliseras un verbe d'action pour une procédure, et tu utiliseras un nom qui décrit le résultat pour une fonction. Pour les variables, tu utiliseras des noms descriptifs sans abuser des abréviations. Si une variable à une très courte portée (par exemple, une boucle sur quelques lignes), tu pourras utiliser des identificateurs d'une seule lettre comme i, j, k. Les identificateurs seront en anglais sans caractères spéciaux (uniquement des lettres, des chiffres et des "underscores"). Cette règle s'applique aussi aux noms des classes, des modules et des "namespaces".

Sache que cette règle est difficile à appliquer, mais elle contribue grandement à faire la différence en un bon et un excellent programmeur.

4. Tu soigneras le style

Tu utiliseras un style consistant dans tous tes codes sources. Tu respecteras les pratiques usuelles, la façon d'écrire du code et les conventions du langage utilisé. Tu indenteras avec des espaces (et non des tabulateurs). Tu n'écriras aucune ligne de plus de 120 caractères. Tu veilleras aussi à limiter la taille des méthodes (~50 lignes) et des modules.

N'hésite pas à utiliser les outils de mise en page (formater) pour garder un style consistant. Les outils d'analyse statique de code (linter) peuvent aussi t'aider à corriger des fautes de style.

5. Tu écriras des commentaires

Tu écriras un court commentaire devant chaque méthode publique. Ce commentaire expliquera ce que fait la méthode. Tu pourras aussi documenter les arguments, le résultat, les "pre-" et "post-conditions", le contrat … Tu peux aussi appliquer cette pratique aux méthodes privées.

Documente aussi les parties plus complexes d'un programme, mais ne documente pas ce qui est trivial. Un commentaire ne doit pas remplacer un mauvais choix de nom pour un identificateur.

6. Tu n'utiliseras aucun "nombre magique" dans ton code.

Toutes les constantes auront un nom descriptif. Une exception est admise ou les cas évidents tels que count=0 ou i+=1.

7. Tu utiliseras un outil de gestion de codes sources

Tu utiliseras toujours un outil de gestion de codes sources tel que "git" pour toutes tes sources. Tu feras des "commits" régulier, avec des commentaires utiles, et tu synchroniseras souvent ton dépôt avec un dépôt distant. Rien ne pourra excuser la perte ou la suppression accidentelle d'un fichier source.

8. Tu ne feras pas de "Copier-Coller"

Tu ne dupliqueras pas de code. Si tu es tenté de faire un "copier-coller", réfléchis à une procédure ou une fonction supplémentaire qui te permettra d'éviter cette pratique. Ce commandement est aussi connu sous le terme DRY : "Don't repeat yourself". Mais attention à ne pas tomber dans l'extrême; privilégiez toujours la simplicité et la lisibilité.

9. Tu feras des tests unitaires

Tu vérifieras les méthodes de ton programme avec des tests unitaires. Ça ne sera pas possible pour toutes les méthodes, mais tu feras au mieux. Tu utiliseras les outils et les bonnes pratiques du moment pour le langage choisi.

10. KISS "Keep It Small and Simple"

Tu ne rendras donc pas ton programme inutilement complexe. Au contraire, tu rechercheras la perfection en le simplifieras au maximum et en implémentant des algorithmes efficaces.

Crédit

L'image en tête d'article est une photo de Darren Halos sur Pexels