Code propre en Java : principes du Clean Code avec exemples

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

Chaque développeur a déjà été confronté à un code impossible à comprendre sans une tasse de café et de la méditation. Des variables nommées a, b, temp, des méthodes de 500 lignes et des commentaires comme « ici c'est de la magie, ne touchez pas » sont des signes certains que le projet se transforme en « legacy ». Clean Code (Code propre) est une philosophie et un ensemble de pratiques qui rendent le code lisible, facile à maintenir et à étendre.

Dans cet article, nous allons décomposer les principes clés du Clean Code en langage Java avec des exemples concrets. Vous apprendrez à écrire un code que vous-même et vos collègues serez reconnaissants de lire dans six mois.

Principe 1 : Des noms explicites

Le nom d'une variable, d'une méthode ou d'une classe doit répondre à trois questions : qu'est-ce que c'est, à quoi ça sert et comment l'utiliser. Un mauvais nom est la principale source de confusion.

Mauvais exemple

public List<Integer> getList(int a) {    List<Integer> list = new ArrayList<>();    for (int i = 0; i < a; i++) {        list.add(i * 2);    }    return list;}

Que fait cette méthode ? Que signifie a ? Retourne-t-elle une liste de nombres pairs ? Ou multiplie-t-elle simplement quelque chose par deux ?

Bon exemple (Clean Code)

public List<Integer> generateEvenNumbers(int count) {    List<Integer> evenNumbers = new ArrayList<>();    for (int i = 0; i < count; i++) {        evenNumbers.add(i * 2);    }    return evenNumbers;}

Maintenant, tout est clair sans commentaires : la méthode génère une liste de nombres pairs d'une longueur donnée.

Règles de nommage

• Classes : des noms (User, PaymentProcessor)
• Méthodes : des verbes (saveUser(), calculateTotal())
• Variables : des noms significatifs (userName, totalPrice)
• Évitez : les abréviations (usrNm), les noms d'une seule lettre (sauf pour les compteurs de boucle i, j)

Principe 2 : Des petites méthodes avec une seule responsabilité

Une méthode ne doit faire qu'une seule chose et la faire bien. Si une méthode peut être décrite avec la conjonction « ET » (elle fait d'abord A, ET ensuite B), alors elle doit être divisée.

Mauvais exemple : monolithe

public void processOrder(Order order) {    // Validation    if (order.getItems().isEmpty()) {        throw new IllegalArgumentException("Order is empty");    }    // Calcul du coût    double total = 0;    for (Item item : order.getItems()) {        total += item.getPrice() * item.getQuantity();    }    // Envoi d'email    EmailService.send(order.getCustomerEmail(), "Your order total: " + total);    // Sauvegarde en BDD    orderRepository.save(order);}

Cette méthode fait 4 choses : valider, calculer, envoyer un email et sauvegarder. Si quelque chose casse, il faudra chercher la cause dans toute la méthode.

Bon exemple : méthodes propres

public void processOrder(Order order) {    validateOrder(order);    double total = calculateTotal(order);    sendConfirmationEmail(order, total);    saveOrder(order);}

private void validateOrder(Order order) {    if (order.getItems().isEmpty()) {        throw new IllegalArgumentException("Order cannot be empty");    }}

private double calculateTotal(Order order) {    return order.getItems().stream()            .mapToDouble(item -> item.getPrice() * item.getQuantity())            .sum();}

private void sendConfirmationEmail(Order order, double total) {    String message = "Your order total: " + total;    EmailService.send(order.getCustomerEmail(), message);}

private void saveOrder(Order order) {    orderRepository.save(order);}

Chaque méthode est une brique. Le