Clean Code en Java : principes et exemples pratiques

Introduction : Pourquoi le code propre n'est pas un luxe, mais une nécessité

Chaque développeur Java a déjà vécu cette situation : en ouvrant un ancien projet, il passe des heures à comprendre ce qu'il a lui-même écrit quelques mois plus tôt. Que dire alors du code des autres ? Le code sale ralentit le développement, augmente le nombre de bugs et démotive l'équipe. Le livre de Robert Martin "Clean Code" est devenu une bible pour les programmeurs, mais ses principes restent souvent abstraits. Dans cet article, nous allons décortiquer les concepts clés du Clean Code en Java avec des exemples concrets que vous pouvez appliquer dès aujourd'hui.

Le code propre ne concerne pas une syntaxe parfaite ou le fait de suivre une mode. Il s'agit de respecter ses collègues, son futur moi et, en fin de compte, l'entreprise. Un code lisible est plus facile à maintenir, à tester et à refactoriser. Voyons comment transformer un code Java de "fonctionnel" à "propre".

1. Des noms significatifs : parlez le langage du domaine métier

Règle : le nom doit répondre aux questions "pourquoi ?", "quoi ?", "comment ?"

Un mauvais nommage est le principal ennemi du code propre. Les variables int a, String d ou List<Integer> list1 n'apportent aucune information. Un bon nom doit révéler l'intention du programmeur.

// Mauvais\nint d; // elapsed time in days\nList<Integer> lst;\n\n// Bon\nint daysSinceCreation;\nList<Integer> customerIds;

Évitez la désinformation

N'utilisez pas accountList s'il ne s'agit pas d'une List, mais par exemple d'un Set ou d'une Map. N'abrégez pas l'évidence : usrNm au lieu de userName.

Noms des classes et des méthodes

\n
• Classes : des noms (Customer, OrderProcessor).
\n
• Méthodes : des verbes (calculateTotal(), saveToDatabase()).
\n
• Variables booléennes : des prédicats (isActive, hasPermission).
\n

// Mauvais\npublic class Data {\n    public void proc() { ... }\n}\n\n// Bon\npublic class InvoiceCalculator {\n    public BigDecimal calculateTotalAmount() { ... }\n}

2. Fonctions : courtes, atomiques et sans effets de bord

Premier principe : une fonction ne doit faire qu'une seule chose

Une fonction idéale en Java fait entre 4 et 20 lignes. Si une fonction fait plus d'une action, il faut la diviser. Un signe classique : si vous pouvez extraire de la fonction une autre fonction avec un nom significatif, faites-le.

// Mauvais : la fonction fait trois choses\npublic void processOrder(Order order) {\n    if (order == null) throw new IllegalArgumentException();\n    // 1. Validation\n    if (order.getItems().isEmpty()) {\n        logger.warn("Empty order");\n        return;\n    }\n    // 2. Calcul du coût\n    BigDecimal total = BigDecimal.ZERO;\n    for (Item item : order.getItems()) {\n        total = total.add(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())));\n    }\n    // 3. Envoi d'email\n    emailService.sendConfirmation(order.getCustomerEmail(), total);\n}\n\n// Bon : chaque fonction fait une seule chose\npublic void processOrder(Order order) {\n    validateOrder(order);\n    BigDecimal total = calculateTotal(order);\n    sendConfirmationEmail(order, total);\n}\n\nprivate void validateOrder(Order order) {\n    if (order == null || order.getItems().isEmpty()) {\n        throw new IllegalArgumentException("Invalid order");\n    }\n}\n\nprivate BigDecimal calculateTotal(Order order) {\n    return order.getItems().stream()\n            .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))\n            .reduce(BigDecimal.ZERO, BigDecimal::add);\n}

Règle du boy-scout : laisse le campement plus propre que tu ne l'as trouvé

Chaque fois que vous modifiez un fichier, améliorez-le : renommez une mauvaise variable, divisez une longue fonction. Cela empêche l'entropie du code.