Convenzioni di denominazione in Java

Il compilatore Java non si preoccupa di come si chiamano le cose, purché vengano rispettate le regole degli identificatori. La community, tuttavia, segue un insieme preciso di convenzioni di denominazione rimaste invariate fin dal rilascio del linguaggio. Rispettarle fa sembrare il codice nativo a chiunque lo legga, e molte ispezioni degli IDE e regole di lint le danno per scontate.

Le convenzioni in sintesi

Esempi nel codice:

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) { ... }
}

Classi, interfacce, enum, record

Usa UpperCamelCase — scrivi in maiuscolo la prima lettera di ogni parola, senza separatori:

• Customer, OrderRepository, HttpClient, XmlParser (gli acronimi vengono di solito trattati come parole: Http, Xml)

Trattare gli acronimi come parole mantiene i confini leggibili: parseHttpUrl è più facile da scansionare di parseHTTPURL, dove tre sequenze di maiuscole si confondono. Lo stesso JDK è incoerente in questo (HttpURLConnection è precedente alla convenzione), quindi in caso di dubbio segui il codice circostante.

I nomi delle classi dovrebbero essere sostantivi: Order, Connection, BankAccount.

Anche le interfacce usano UpperCamelCase. Due pattern di denominazione comuni:

• Aggettivo che termina in -able: Comparable, Runnable, Serializable.
• Sostantivo che indica un ruolo: List, Repository, Connection.

Evita il vecchio prefisso I della notazione ungherese (ICustomer) — il codice Java non lo fa. La stessa regola UpperCamelCase si applica a enum e interfacce.

Metodi e variabili

Usa lowerCamelCase: prima parola in minuscolo, ogni parola successiva con l'iniziale maiuscola:

• calculateTotal, parseDate, getUserName, index, lineCount.

I nomi dei metodi dovrebbero essere verbi o frasi verbali:

• save, findById, validate, parseJson.

Prefissi verbali comuni:

• get / set — accessor e mutator (chiamati anche getter e setter).
• is / has / can — restituisce un boolean: isEmpty, hasNext, canExecute.
• to — restituisce una forma convertita: toString, toUpperCase.
• from — metodo factory: LocalDate.from(temporal).

I nomi delle variabili dovrebbero descrivere cosa è il valore, non come viene usato. Preferisci customer a obj, lineCount a n. I nomi con una sola lettera vanno bene per gli indici di ciclo (i, j) e per le variabili locali di breve vita in cui il tipo è ovvio (var p = new Point(...)).

Costanti

Una costante è un campo static final. Usa 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);

Le variabili final locali (binding usa-e-getta all'interno di un metodo) NON sono considerate costanti nello stesso senso — mantienile in lowerCamelCase:

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

Package

I nomi dei package sono tutti minuscoli, separati da punti. La convenzione della community è usare un dominio invertito che si controlla:

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

Evita underscore o lettere maiuscole nei nomi dei package — sono considerati non idiomatici.

Parametri di tipo

I parametri di tipo generici sono di solito singole lettere maiuscole. Le convenzioni di fatto:

• T — tipo (generico)
• E — elemento (in una collezione)
• K — chiave
• V — valore
• R — tipo di ritorno
• S, U — secondo, terzo parametro di tipo quando ce n'è più di uno

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

Per API complesse in cui una singola lettera non è chiara, usa un nome descrittivo in UpperCamelCase che termina con T: RequestT, ResponseT. Questo è raro.

Boolean

I nomi di variabili e metodi boolean sono di solito formulati come predicati:

• isActive, hasNext, canExecute, shouldRetry.

Evita nomi negativi come isNotEmpty — si leggono male se combinati con !.

Errori di denominazione da evitare

• Nomi con una sola lettera fuori da un ciclo stretto: int s = 100 non dice nulla.
• Notazione ungherese: strName, iCount — Java è tipizzato staticamente, l'IDE mostra il tipo.
• Suffissi numerici: total1, total2, processData2. Se hai bisogno di due, trova una distinzione reale.
• Costanti in stile enum tutto maiuscolo per tutto ciò che è final: solo le vere costanti a livello di modulo ricevono il trattamento UPPER_SNAKE.
• Casing inconsistente tra elementi adiacenti: se un metodo è getUserId, il vicino non dovrebbe essere get_email.

Una dimostrazione

Ogni nome qui segue la convenzione standard: classe in UpperCamelCase, costante in UPPER_SNAKE_CASE, variabili in lowerCamelCase, boolean nominato come predicato.

Cosa viene dopo

Tipi di dati Java introduce i tipi primitivi e di riferimento di Java — i mattoni fondamentali di cui è composta ogni variabile.

Esercitati