Bonne pratiques

Les bonnes pratiques données ci-dessous viennent principalement de la chaine YouTube "Code Aestetics" et du language de programmation Rust

Nommer les choses

• Eviter d'utiliser des nombres random dans le code et les remplacer par des constantes
• Ne pas abréger le noms des méthodes ou le nom des variables
• Ne pas répèter les types dans les noms des variables
• Spécifier les unités dans les variables, ou mieux, créer un type qui le représente
• Eviter d'utiliser des noms/préfixes génériques tel que "I", "Utils", "Helper", "Abstract" dans les noms des classes
• Il n'est pas nécessaire de donner des informations sur les détails de fonctionnement (par exemple écrire "Interface" ou "I" dans le nom d'une interface n'est pas nécessaire)

Eviter les commentaires et rendre le code plus robuste

• Eviter d'utiliser trop de commentaires, car ils peuvent devenir obsolètes et ne sont pas nécessaire quand le code est proprement documenté. A la place essayer de rendre le code si clair qu'il s'exprimme comme le commentaire.
• Utiliser des commentaires quand l'implémentation semble quelque peu bizarre (par exemple pour des raisons d'optimisation)
• Les conditions peuvent être extraites dans des méthodes séparées
• Utiliser des enums pour tous les états fixent pour empécher des états impossibles d'être représenter
• Si possible utiliser des types tel que "Option" ou "Result" pour obliger de prendre en compte les cas de valeurs null ou d'erreurs

Améliorer la lisibilité du code encore plus

• Eviter d'utiliser plus de 3 niveau d'intendation dans une méthode
  • Extraire des bouts d'une méthode dans plusieurs autres
  • Notter les conditions d'une méthode au desus (cela permet de supprimer les else)
• Ecrire une documentation (comment utiliser le code) de très bonne qualité et la garder à jour.
  • Décrire le but d'une classe et des interfaces et ce qu'elle représente
  • Décrire les attentes que les interfaces ont par rapport à leurs implémentations (comment elles doivent gérer X ou Y)
  • Décrire les buts des méthodes, leurs préconditoins et leurs post-conditions

Principes orienté objet

• Eviter de faire des classes intuiles (qui ne font que très peu de choses) → data class
• Eviter de faires des classes qui font tout (classes dieu)
• Eviter d'appeller des méthodes d'objets qui ne sont pas des attributs, des paramètres, créé par, ou de même classe dans une méthode. → eviter d'appeller des méthodes d'objets retournés par une autre méthode. Et eviter de les donner en premier lieu
• Rendre tous les attributs private et rendre un maximum de classes immuable si possible
• Vérifier les paramètres des méthodes et des constructeurs pour empécher que des états invalides se présentent (par exemple avec des valeurs null)
• Quand quelque chose en lien direct avec les attributs est renvoyé, s'assurer qu'il est immuable
• Eviter de faire ensorte que les autres classes fassent le boulot d'une classe à sa place → extraire des bouts de méthode dans une autre classe
• Eviter les dépendences mutuelles ou circulaires entre classes
• Empécher l'héritage en metant final sur toutes les classes

MVC et MVP

• Les classes métier ne doivent avoir aucun contact avec des classes de la vue
• La vue peut être liée au superviseur par le biais d'une interface (on crée d'abord le superviseur, crée une vue qui implémente une interface de vue en lui passant le superviseur, on donne la vue à travers l'interface au superviseur)
• Pour des objets qui doivent avoir un état partagé entre tous les supervisuers on peut utiliser une Factory qui va être passée à tous les supervisuers et qui va garder en mémoire l'objet en cours pour le créer et le récupèrer)
• Dans le cas d'un presenter (MVP) les superviseurs vont récupérer les informations brutes depuis les classes métier, les process et les afficher dans la vue
• Dans le cas d'un controlleur (MVC) les superviseurs vont récupérer les informations déjà bien formattée et vont simplmeent les mettre dans la vue sans plus de traitement
• Les classes métier ne doivent pas dépendre du superviseur

Tests unitaires

• Créer une interface d'aléatoire et une fausse et vrai classe aléatoire pour les tests (et faire une surcharge de constructeurs)
• Tenter d'obtenir un code coverage de 90% au minimum sur toutes les classes
• Décrire les tests sous forme de "Étant donné une condition Quand une action Alors une/plusieurs postcondition"

Git

• Do not make bunduled commits of a lot of things, really commit one thing at the time
• You can use emojis in your commits to represent differnet sort of tasks (documentation, refactoring, testing, etc) see GitMoji
• Add a README (you can pimp it using shields, GIF, installation instructions, usage instructions, license information, general description, and features)