Bonne pratiques

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

Nomer 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 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

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

Eviter de faire des classes intuiles (qui ne font que très peu de choses) → data class

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

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

Créer une interface d'aléatoire et une fausse et vrai classe aléatoire pour les tests (et faire une surcharge de constructeurs)

Décrire les tests sous forme de "Étant donné une condition Quand une action Alors une/plusieurs postcondition"