Conventions de nommage Java

Le compilateur Java se fiche de la façon dont vous nommez les choses, du moment que les règles d'identificateurs sont respectées. La communauté, en revanche, suit un ensemble strict de conventions de nommage qui sont les mêmes depuis la création du langage. Les respecter donne à votre code un aspect naturel pour quiconque le lit, et de nombreuses inspections d'IDE et règles de lint les supposent acquises.

Les conventions en un coup d'œil

Exemples en code :

package com.example.billing;

public class InvoicePrinter {
    public static final int MAX_LINE_WIDTH = 80;

    private int lineCount;

    public void print(Invoice invoice) {
        for (LineItem item : invoice.getItems()) {
            renderLine(item);
        }
    }

    private void renderLine(LineItem item) { ... }
}

Classes, interfaces, enums, records

Utilisez UpperCamelCase — mettez en majuscule la première lettre de chaque mot, sans séparateur :

• Customer, OrderRepository, HttpClient, XmlParser (les acronymes sont généralement traités comme des mots : Http, Xml)

Traiter les acronymes comme des mots rend les frontières lisibles : parseHttpUrl est plus facile à parcourir que parseHTTPURL, où trois suites de majuscules se fondent les unes dans les autres. Le JDK lui-même est incohérent sur ce point (HttpURLConnection est antérieur à la convention), donc en cas de doute, suivez le code environnant.

Les noms de classes doivent être des noms communs : Order, Connection, BankAccount.

Les interfaces sont également en UpperCamelCase. Deux patterns de nommage courants :

• Adjectif se terminant par -able : Comparable, Runnable, Serializable.
• Nom désignant un rôle : List, Repository, Connection.

Évitez l'ancien préfixe I de la notation hongroise (ICustomer) — le code Java ne fait pas cela. La même règle UpperCamelCase s'applique aux enums et aux interfaces.

Méthodes et variables

Utilisez lowerCamelCase : premier mot en minuscules, chaque mot suivant avec une majuscule :

• calculateTotal, parseDate, getUserName, index, lineCount.

Les noms de méthodes doivent être des verbes ou des syntagmes verbaux :

• save, findById, validate, parseJson.

Préfixes verbaux courants :

• get / set — accesseur et mutateur (aussi appelés getter et setter).
• is / has / can — retourne un boolean : isEmpty, hasNext, canExecute.
• to — retourne une forme convertie : toString, toUpperCase.
• from — méthode de fabrique : LocalDate.from(temporal).

Les noms de variables doivent décrire ce qu'est la valeur, et non comment elle est utilisée. Préférez customer à obj, lineCount à n. Les noms à une seule lettre sont acceptables pour les indices de boucle (i, j) et les variables locales de courte durée où le type est évident (var p = new Point(...)).

Constantes

Une constante est un champ static final. Utilisez UPPER_SNAKE_CASE :

public static final int MAX_RETRIES = 3;
public static final String DEFAULT_GREETING = "Hello";
public static final Duration TIMEOUT = Duration.ofSeconds(30);

Les variables locales final (liaisons à usage unique à l'intérieur d'une méthode) ne sont PAS considérées comme des constantes au même titre — gardez-les en lowerCamelCase :

public void process(Order o) {
    final int maxAttempts = 3;   // not MAX_ATTEMPTS
    ...
}

Packages

Les noms de packages sont entièrement en minuscules, séparés par des points. La convention de la communauté est d'utiliser un domaine inversé que vous contrôlez :

• com.google.guava
• org.apache.commons.lang3
• com.example.billing.invoices

Évitez les tirets bas ou les majuscules dans les noms de packages — ils sont considérés comme non idiomatiques.

Paramètres de type

Les paramètres de type générique sont généralement des lettres majuscules uniques. Les conventions de facto :

• T — type (général)
• E — élément (dans une collection)
• K — clé
• V — valeur
• R — type de retour
• S, U — deuxième, troisième paramètre de type quand il y en a plus d'un

public interface List<E> { ... }
public interface Map<K, V> { ... }
public interface Function<T, R> { ... }

Pour les API complexes où une seule lettre manque de clarté, utilisez un nom descriptif en UpperCamelCase se terminant par T : RequestT, ResponseT. C'est rare.

Booléens

Les noms de variables et de méthodes boolean sont généralement formulés comme des prédicats :

• isActive, hasNext, canExecute, shouldRetry.

Évitez les noms négatifs comme isNotEmpty — ils sont difficiles à lire quand ils sont combinés avec !.

Les mauvaises pratiques de nommage à éviter

• Noms à une lettre en dehors d'une boucle serrée : int s = 100 ne dit rien.
• Notation hongroise : strName, iCount — Java est statiquement typé, l'IDE affiche le type.
• Suffixes numériques : total1, total2, processData2. Si vous en avez besoin de deux, trouvez une vraie distinction.
• Constantes de style enum tout en majuscules pour tout ce qui est final : seules les véritables constantes au niveau du module reçoivent le traitement UPPER_SNAKE.
• Casse incohérente entre éléments frères : si une méthode est getUserId, la voisine ne devrait pas être get_email.

Une démonstration

Chaque nom ici suit la convention standard : classe en UpperCamelCase, constante en UPPER_SNAKE_CASE, variables en lowerCamelCase, boolean nommé comme un prédicat.

Prochaine étape

Les types de données Java présente les types primitifs et de référence de Java — les blocs de construction dont toute variable est faite.

Pratique