Convenzioni di Codifica Java

Le convenzioni di codifica sono le regole condivise che fanno sembrare il codice Java scritto da una sola persona, anche quando un team di cinquanta sviluppatori vi mette mano. Riguardano la denominazione, l'indentazione, il posizionamento delle parentesi graffe, la lunghezza delle righe e il layout dei file — niente di cui il compilatore si preoccupi, ma tutto ciò che determina se il lettore successivo (spesso tu stesso, mesi dopo) riesce a scorrere un metodo in pochi secondi o deve decodificarlo faticosamente. Java ha convenzioni insolitamente forti perché sono state pubblicate presto, nelle Code Conventions for the Java Programming Language originali di Sun, e da allora sono rimaste notevolmente stabili.

Perché le convenzioni contano più del compilatore

La JVM esegue int X=1;if(X>0){return"a";} esattamente alla stessa velocità del codice ben formattato. Le convenzioni esistono per gli esseri umani: il codice viene letto molto più spesso di quanto venga scritto, e uno stile coerente elimina un livello di attrito a ogni lettura. Un secondo vantaggio pratico è la pulizia dei diff — quando tutti formattano allo stesso modo, un diff del controllo di versione mostra vere modifiche logiche invece del rumore della riformattazione. La maggior parte dei team applica automaticamente un unico stile (con un formattatore) proprio per fare in modo che lo stile smetta di essere oggetto di discussione in sede di code review.

Denominazione: la convenzione che usi a ogni riga

I nomi portano quasi tutto il significato di un programma, e le regole di denominazione di Java sono quasi universali nell'ecosistema:

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;
  }
}

Evita le abbreviazioni che non sono standard nel settore (accelerationTime, non accTime), e lascia che la lunghezza del nome corrisponda al suo ambito — un indice di ciclo può essere i, ma un campo che vive per tutta la durata di un oggetto merita una parola completa.

Formattazione: parentesi graffe, indentazione e lunghezza delle righe

Java fa un uso prevalente dello stile K&R per le parentesi graffe: la parentesi graffa aperta si trova sulla stessa riga della dichiarazione, e la parentesi graffa chiusa è allineata sotto l'inizio dell'istruzione. L'indentazione standard è di 4 spazi (mai tabulazioni nelle guide ufficiali), e le righe vengono mantenute a una larghezza ragionevole — il limite classico era di 80 colonne; guide moderne come quella di Google usano 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();
}

Alcune regole che prevengono i commenti di revisione più comuni: un'istruzione per riga, una riga vuota tra i metodi, uno spazio dopo le parole chiave (if (, non if(), e nessuno spazio bianco finale.

Guide di stile riconosciute

Raramente si inventano convenzioni da zero — si adotta una guida pubblicata e si lascia che uno strumento la applichi:

La guida specifica conta meno che sceglierne una e applicarla in modo coerente. Strumenti come Checkstyle (verifica lo stile e fa fallire la build in caso di violazioni), Spotless e google-java-format (formattazione automatica al salvataggio o al commit) e i formattatori dell'IDE eliminano completamente l'elemento umano.

Un esempio pratico: regole di convenzione nel codice funzionante

Il compilatore è cieco allo stile, quindi un programma eseguibile non può "testare" la formattazione direttamente. Ciò che può fare è esercitare le regole di denominazione e struttura in codice reale — costanti, metodi in camelCase, parentesi graffe K&R, variabili tipizzate con interfacce — e stampare risultati che dimostrano che ogni elemento sta svolgendo il suo lavoro.

Cosa ricavare dall'esecuzione:

• MAX_RETRIES constant = 3 mostra la costante UPPER_SNAKE_CASE in uso. Dichiarare i valori come private static final e nominarli in upper-snake-case segnala "questo non cambia mai" a ogni lettore a colpo d'occhio — la convenzione codifica l'intento che il compilatore non può trasmettere.
• grossPrice(100.00) = 120.00 proviene da un metodo il cui nome verbale in camelCase si legge come un'istruzione. Il parametro netPrice e l'uso di TAX_RATE nel corpo rendono il calcolo autodocumentante; lo si comprende senza un commento.
• grades = [A, B, C] è prodotto da classify, scritto in K&R brace style con parentesi graffe esplicite su ogni ramo — anche i rami con un solo return. Quelle parentesi graffe sono ciò che impedisce a una modifica successiva di creare accidentalmente un dangling statement.
• total name length = 10 proviene da un enhanced for-loop su una List<String> dichiarata con il tipo interfaccia a sinistra, non ArrayList. Programmare verso l'interfaccia è la convenzione che mantiene il resto del codice libero di scambiare implementazioni.
• totalLength is even mostra un boolean denominato come una domanda (isEven) che alimenta un ternario breve e monouso. Queste convenzioni sono invisibili quando seguite e stranianti quando violate — ed è proprio per questo che i team le automatizzano.

Cosa tratta il resto di questa parte

Le convenzioni sono il livello superficiale; i capitoli successivi passano da come il codice appare a come viene strutturato:

• Clean Code — pratiche che mantengono i metodi piccoli e leggibili al di là della formattazione.
• Naming Best Practices — scegliere nomi che si spiegano da soli.
• Immutability Best Practices — progettare oggetti che non possono cambiare dopo la costruzione.
• SOLID Principles — le regole di progettazione che determinano come le classi dipendono l'una dall'altra.

Esercitazione