Code propre en Java : les règles qui sauveront votre projet

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

Imaginez que vous entrez dans un projet existant. Les classes s'appellent Class1, Manager, UltraProcessor. Les méthodes font tout à la fois : requête en base, rendu HTML, envoi d'email. Et les variables — x, y, temp. Cela vous dit quelque chose ? Si oui, vous savez à quelle vitesse un tel code transforme la vie d'un développeur en enfer.

Le code propre en Java n'est pas une question de pédanterie. C'est une question de respect envers vos collègues, envers votre futur vous-même et envers l'entreprise. Un code sale ralentit le développement de 2 à 3 fois, rend les bugs insaisissables et le refactoring impossible. Dans cet article, nous allons détailler des règles concrètes qui vous aideront à écrire un code que l'on a envie de lire et de maintenir.

Règle n°1 : Le nommage — 50% du succès

Robert Martin (Oncle Bob) dans son livre « Clean Code » affirme : un bon nom remplace un commentaire. Les développeurs Java pèchent souvent par des noms abstraits. Corrigeons cela.

Variables : dites ce que vous stockez

Mauvais :

int d; // elapsed time in days

Bon :

int elapsedTimeInDays;

Mauvais :

List<String> list = new ArrayList<>();

Bon :

List<String> customerNames = new ArrayList<>();

Méthodes : verbe + contexte

Une méthode doit répondre à la question « que fait-elle ? ». Évitez les mots génériques comme process, handle, doStuff.

Mauvais :

public void process(int id) {\n    // 50 lignes de code : vérification, calcul, envoi d'email\n}

Bon :

public void sendEmailConfirmation(int orderId) {\n    // uniquement la logique d'envoi d'email\n}

Classes : noms sans suffixes parasites

Évitez Manager, Processor, Util, sauf si justifié. Une classe doit refléter une entité.

Mauvais : DataProcessor, UserManager

Bon : UserRepository, InvoiceCalculator, EmailSender

Règle n°2 : Méthodes courtes et mono-tâche

Règle d'or : une méthode = une responsabilité. Si une méthode dépasse 15-20 lignes, il est probable qu'elle doive être divisée. Cela améliore la lisibilité du code Java et simplifie les tests.

Exemple de refactoring

Avant :

public boolean isValidOrder(Order order) {\n    if (order == null) return false;\n    if (order.getItems().isEmpty()) return false;\n    double total = 0;\n    for (Item item : order.getItems()) {\n        total += item.getPrice() * item.getQuantity();\n    }\n    if (total > 10000) {\n        // vérification de la limite de crédit\n        User user = userRepository.findById(order.getUserId());\n        return user.getCreditLimit() >= total;\n    }\n    return true;\n}

Après :

public boolean isValidOrder(Order order) {\n    if (isOrderNullOrEmpty(order)) return false;\n    double total = calculateTotal(order);\n    if (isHighValueOrder(total)) {\n        return hasSufficientCredit(order.getUserId(), total);\n    }\n    return true;\n}\n\nprivate boolean isOrderNullOrEmpty(Order order) {\n    return order == null || order.getItems().isEmpty();\n}\n\nprivate double calculateTotal(Order order) {\n    return order.getItems().stream()\n            .mapToDouble(item -> item.getPrice() * item.getQuantity())\n            .sum();\n}\n\nprivate boolean isHighValueOrder(double total) {\n    return total > 10000;\n}\n\nprivate boolean hasSufficientCredit(int userId, double total) {\n    User user = userRepository.findById(userId);\n    return user.getCreditLimit() >= total;\n}

Règle n°3 : Commentaires — seulement quand on ne peut pas faire autrement

Un commentaire est souvent une excuse pour un mauvais code. Au lieu d'écrire « // obtie