Astuces de refactoring : Comment éviter les ifs imbriqués

Aujourd'hui, on change un peu de sujet. On va se plonger dans le code et voir comment éviter l'enfer des ifs imbriqués.
Un ami m'a récemment partagé un article sur le refactoring, et ça m'a donné envie de partager ma propre approche avec vous. On va prendre une fonction simple mais difficile à lire et la rendre plus claire et maintenable.
Je vais vous montrer comment utiliser des méthodes spécifiques pour vérifier les conditions et comment appliquer les early returns pour améliorer la lisibilité. Que vous soyez débutant ou expérimenté, ces astuces devraient vous aider à mieux structurer votre code.
N'hésitez pas à laisser vos retours en commentaire et à me dire si ce format vous plaît. Je pourrais aborder d'autres sujets ou des exemples plus complexes dans de futures vidéos.
À très vite !

[@nathansmrl]

Salut, je ne connais pas grand chose en code et je te suis principalement pour la série sur le SaaS mais j’ai bien aimé ce format: pédagogue et instructif. J’ai l’impression que le early return, en plus de rendre le code plus lisible permet aussi un léger gain de performance en fonction des situations, est-ce que je me trompe ?

[@mel-mouk]

Merci pour le retour :) Ça peut parfois améliorer un peu les performances selon le scénario, mais c'est assez négligeable. Dans la plupart des cas on aura toujours le même nombre de calcul à faire

[@_Greenflag_]

Partie 2 : éviter les magics number, les mettre en constantes Puis ce que j'aurais fait perso c'est de découper tout cela en petites fonctions (oui elles vont quasi faire une ligne chacune), mais qui seront réutilisables et avec un naming explicite, genre : function driveHasMinimumRating(rating) { return driver.rating > MIN_DRIVER_RATING } (et après, pourquoi ne pas utiliser typescript?)

[@mel-mouk]

Complètement d’accord avec le point sur les magic Numbers. Perso je ne les met pas forcément en constante en JS/TS, j’ai plutôt tendance à faire des objets de configs qui regroupe les infos métier mais c’est la même idée. En C, python … la je fait des constantes Pour le découpage, c’est assez courant ce que tu proposes oui. Mais perso je ne suis pas trop fan des fonctions d’une ligne tant qu’elles sont pas effectivement réutilisées. Je préfères attendre que ça se pose effectivement et ne pas trop anticiper. Tant que la fonction reste en dessous de 25-30 lignes je ne re découpe pas forcément Pour le language, simplement pour coller au code 😅 la base était en JS donc je refacto en JS. Mais j’utilise beaucoup typescript dans mes projets

[@greatso9018]

Ton avis semble très influencé par le livre "Clean Code" de Robert C Martin. Selon moi, avoir beaucoup de petites fonctions et beaucoup de constantes, rend le code parfaitement illisible. Après le refactor de la vidéo, je comprend très bien les rêgles métier qui se dégagent du code. Le code se lit de haut en bas, et j'ai tout le contexte devant les yeux. En séparant le code en petites fonctions, et en ajoutant des constantes le contexte se disperse, les règles métiers sont moins claires, et mes yeux doivent chercher quelle fonction fait référence à quoi. C'est satisfaisant, parce que tout est rangé dans des petites boites, mais ce n'est pas efficace.