Conventions de codage Java et guides de style

Les conventions de codage sont les règles partagées qui font paraître le code Java comme s'il avait été écrit par une seule personne, même lorsqu'une équipe de cinquante développeurs y touche. Elles couvrent le nommage, l'indentation, le placement des accolades, la longueur des lignes et la structure des fichiers — aucun de ces éléments n'intéresse le compilateur, mais tous décident si le prochain lecteur (souvent vous-même, des mois plus tard) peut parcourir une méthode en quelques secondes ou doit la décoder. Java possède des conventions particulièrement solides car elles ont été publiées tôt, dans les Code Conventions for the Java Programming Language originales de Sun, et elles sont restées remarquablement stables depuis.

Pourquoi les conventions importent plus que le compilateur

La JVM exécute int X=1;if(X>0){return"a";} exactement aussi vite que du code bien formaté. Les conventions existent pour les humains : le code est lu bien plus souvent qu'il n'est écrit, et un style cohérent supprime une couche de friction à chaque lecture. Un deuxième avantage pratique est la propreté des diffs — lorsque tout le monde formate de la même façon, un diff de contrôle de version montre de vraies modifications logiques plutôt que du bruit de reformatage. La plupart des équipes appliquent un style unique automatiquement (avec un formateur) précisément pour que le style cesse d'être un sujet de discussion lors des revues de code.

Nommage : la convention que vous utilisez à chaque ligne

Les noms portent presque toute la signification d'un programme, et les règles de nommage Java sont presque universelles dans l'écosystème :

Élément	Convention	Exemple
Classe / interface / enum	`PascalCase`, substantif	`OrderService`, `HttpClient`
Méthode	`camelCase`, phrase verbale	`parseDate`, `isEmpty`
Champ / variable locale	`camelCase`, substantif	`retryCount`, `userName`
Constante (`static final`)	`UPPER_SNAKE_CASE`	`MAX_RETRIES`, `DEFAULT_PORT`
Paramètre de type	lettre majuscule unique	`T`, `K`, `V`, `E`
Package	tout en minuscules, pointé	`com.example.billing`

public class InvoiceCalculator {        // PascalCase class
  private static final int MAX_ITEMS = 100;  // UPPER_SNAKE_CASE constant
  private int lineCount;                 // camelCase field

  public boolean isOverLimit() {         // camelCase verb, boolean reads as a question
    return lineCount > MAX_ITEMS;
  }
}

Évitez les abréviations qui ne sont pas des standards du secteur (accelerationTime, pas accTime), et faites en sorte que la longueur d'un nom corresponde à sa portée — un indice de boucle peut être i, mais un champ qui vit toute la durée de vie d'un objet mérite un mot complet.

Formatage : accolades, indentation et longueur des lignes

Java utilise massivement le style d'accolades K&R : l'accolade ouvrante se trouve sur la même ligne que la déclaration, et l'accolade fermante s'aligne sous le début de cette instruction. L'indentation standard est de 4 espaces (jamais de tabulations dans les guides officiels), et les lignes sont maintenues à une largeur raisonnable — la limite classique était de 80 colonnes ; les guides modernes comme celui de Google utilisent 100.

// K&R: opening brace on the same line, always use braces
if (user.isActive()) {
  sendWelcome(user);
} else {
  queueReminder(user);
}

// Even a one-line body gets braces — it prevents the classic "dangling statement" bug
for (Order order : orders) {
  total += order.amount();
}

Quelques règles qui évitent les commentaires de revue les plus courants : une instruction par ligne, une ligne vide entre les méthodes, un espace après les mots-clés (if (, pas if(), et pas d'espaces en fin de ligne.

Guides de style reconnus

Vous inventez rarement des conventions de toutes pièces — vous adoptez un guide publié et laissez un outil l'appliquer :

Guide	Indentation	Largeur de ligne	Notes
Oracle/Sun Code Conventions	4 espaces	80	L'original ; fondateur mais daté
Google Java Style Guide	2 espaces	100	Largement adopté ; soutenu par l'outil `google-java-format`
Android (AOSP)	4 espaces	100	Basé sur celui de Google, adapté pour Android

Le guide spécifique importe moins que le choix d'un seul et son application cohérente. Des outils comme Checkstyle (vérifie le style et fait échouer le build en cas de violations), Spotless et google-java-format (formatage automatique à la sauvegarde ou au commit), et les formateurs d'IDE éliminent entièrement l'élément humain.

Un exemple complet : les règles de convention dans du code fonctionnel

Le compilateur est aveugle au style, donc un programme exécutable ne peut pas « tester » le formatage directement. Ce qu'il peut faire, c'est exercer les règles de nommage et de structure dans du vrai code — constantes, méthodes en camelCase, accolades K&R, variables typées par interface — et afficher des résultats qui prouvent que chaque élément fait son travail.

java— editable, runs on the server

import java.util.List;
import java.util.ArrayList;

public class CodingConventionsDemo {

// Constants are UPPER_SNAKE_CASE. Classes are PascalCase, methods/fields are camelCase.
  private static final int MAX_RETRIES = 3;
  private static final double TAX_RATE = 0.20;

// A method name is a verb phrase; it reads like an instruction.
  private static double grossPrice(double netPrice) {
    return netPrice * (1 + TAX_RATE);
  }

// Braces use K&R style: opening brace on the same line, always braces even for one statement.
  private static String classify(int score) {
    if (score >= 90) {
      return "A";
    } else if (score >= 75) {
      return "B";
    } else {
      return "C";
    }
  }

public static void main(String[] args) {
    // Local variables: descriptive camelCase names, declared close to first use.
    double net = 100.0;
    System.out.printf("MAX_RETRIES constant = %d%n", MAX_RETRIES);
    System.out.printf("grossPrice(%.2f) = %.2f%n", net, grossPrice(net));

// One statement per line; consistent 4-space (here 2 in source) indentation.
    int[] scores = {95, 80, 60};
    List<String> grades = new ArrayList<>();
    for (int s : scores) {
      grades.add(classify(s));
    }
    System.out.println("grades = " + grades);

// Prefer the enhanced for-loop and interface types on the left (List, not ArrayList).
    List<String> names = List.of("ann", "bob", "cleo");
    int totalLength = 0;
    for (String name : names) {
      totalLength += name.length();
    }
    System.out.println("total name length = " + totalLength);

// Booleans read as questions; ternaries stay short and single-purpose.
    boolean isEven = totalLength % 2 == 0;
    System.out.println("totalLength is " + (isEven ? "even" : "odd"));
  }
}

Ce qu'il faut retenir de l'exécution :

MAX_RETRIES constant = 3 montre la constante UPPER_SNAKE_CASE en action. Déclarer des valeurs avec private static final et les nommer en majuscules-snake-case signale « cela ne change jamais » à tout lecteur au premier coup d'œil — la convention encode l'intention que le compilateur ne peut pas transmettre.
grossPrice(100.00) = 120.00 provient d'une méthode dont le nom en camelCase se lit comme une instruction. Le paramètre netPrice et l'utilisation de TAX_RATE dans le corps rendent le calcul auto-documenté ; vous le comprenez sans commentaire.
grades = [A, B, C] est produit par classify, écrite en style d'accolades K&R avec des accolades explicites sur chaque branche — même les bras à retour unique. Ces accolades empêchent une modification ultérieure de créer accidentellement une instruction pendante.
total name length = 10 provient d'une boucle for améliorée sur une List<String> déclarée avec le type interface à gauche, pas ArrayList. Coder vers l'interface est la convention qui permet au reste du code de substituer librement les implémentations.
totalLength is even montre un boolean nommé comme une question (isEven) alimentant un ternaire court et à usage unique. Les conventions comme celles-ci sont invisibles quand elles sont suivies et choquantes quand elles sont enfreintes — c'est précisément pourquoi les équipes les automatisent.

Ce que couvre le reste de cette partie

Les conventions sont la couche de surface ; les chapitres suivants passent de la façon dont le code ressemble à la façon dont il est structuré :

Clean Code — pratiques qui maintiennent les méthodes courtes et lisibles au-delà du formatage.
Naming Best Practices — choisir des noms qui s'expliquent d'eux-mêmes.
Immutability Best Practices — concevoir des objets qui ne peuvent pas changer après leur construction.
SOLID Principles — les règles de conception qui façonnent la façon dont les classes dépendent les unes des autres.

Pratique

Votre équipe examine une pull request et quelqu'un déclare une valeur de configuration comme 'private static final int maxRetries = 3;'. En suivant les conventions de codage Java standard, quel est le problème ?

Une constante 'static final' doit être nommée en UPPER_SNAKE_CASE, donc elle devrait s'appeler 'MAX_RETRIES'Les constantes ne peuvent pas être 'private' en Java, donc le modificateur d'accès doit être suppriméLe champ doit utiliser 'PascalCase' car il est déclaré au niveau de la classeLes constantes entières doivent être déclarées sans 'final' pour que la JVM puisse les optimiser