Clean Code

Ouvrez un fichier qui n’existe pas en Python, open() lève un FileNotFoundError qui remonte hors de votre fonction. Faites la même chose en Go, os.ReadFile vous renvoie une valeur error accompagnée d’un slice d’octets nil. Même échec, deux formes de code complètement différentes autour. La différence n’est pas cosmétique. Elle décide si l’appelant peut ignorer l’échec par accident, et si le compilateur le repère quand ça arrive. Qu’est-ce que les exceptions et les valeurs d’erreur font réellement différemment ? Une exception est un flux de contrôle qui saute. Quelque chose échoue, la fonction lève, et l’exécution quitte la pile d’appels en cours pour atterrir dans le premier bloc catch ou except correspondant, peu importe le nombre de niveaux au-dessus. La signature de la fonction ne donne aucun indice que cela puisse arriver. loadConfig(path: string): Config en TypeScript ressemble exactement à une fonction qui ne peut pas échouer, jusqu’à ce qu’elle lève une exception pour un fichier manquant. ...

Une classe qui enregistre un utilisateur en base, lui envoie un email de bienvenue et met en forme un reçu n’est qu’à un changement de casser deux fonctionnalités qui n’ont rien à voir entre elles. Vous touchez le template de l’email et vous risquez l’écriture en base. Vous touchez la mise en page du reçu et vous risquez l’email. SOLID, ce sont cinq règles qui attaquent ce type d’enchevêtrement sous des angles différents, et elles partagent une idée : une classe doit changer pour une seule raison, et le reste du code doit dépendre de ce qu’une chose promet de faire, pas de la façon dont elle le fait. ...

Voici une classe que vous ne pouvez pas tester unitairement sans une base de données active et un serveur SMTP opérationnel : 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService construit lui-même ses SqlOrderRepository et SmtpEmailSender avec new, chaîne de connexion comprise. Chaque test qui touche à PlaceOrder a besoin d’une vraie base de données Orders et d’un vrai serveur de mail, sinon il échoue avant même que votre assertion s’exécute. La logique que vous voulez tester tient en deux lignes : enregistrer la commande, envoyer la confirmation. Elle est soudée à deux classes concrètes que vous ne pouvez pas remplacer. ...

Vous ouvrez une fonction pour corriger un bug d’une ligne et quarante minutes plus tard, vous êtes encore en train de suivre quelle branche définit quelle variable. Trois tâches sans rapport entre elles sont soudées dans un seul bloc, et aucune n’a de nom. Vous tirez un fil et vous ne pouvez pas dire lesquels des autres bougent. C’est ça, le spaghetti code, et le nom n’a rien à voir avec l’indentation ou le style de nommage. Il décrit le flux de contrôle : l’exécution saute entre les conditions comme un brin de pâtes qui croise tous les autres dans le bol, et suivre un seul chemin jusqu’au bout signifie garder quatre niveaux de if en tête à la fois. ...