1. Introduzione
Nella programmazione lo stile non riguarda la moda, ma la sopravvivenza. Java è un linguaggio su cui lavorano team numerosi e, se ognuno scrive «come è abituato», il progetto si trasforma rapidamente in un insieme di pezzi scollegati, in cui riuscirà a orientarsi solo l’autore (e non sempre).
Stile del codice — è un insieme di regole che rendono il codice ugualmente leggibile per tutti. È come la segnaletica stradale: se la ignori, il traffico si trasforma rapidamente in caos.
Perché è importante?
- Leggibilità: il codice viene letto più spesso di quanto venga scritto. Uno stile scadente è come la calligrafia illeggibile di un medico: nessuno capirà cosa c’è scritto.
- Manutenibilità: se il codice è scritto secondo le regole, è più facile modificarlo e c’è meno probabilità di rompere qualcosa per sbaglio.
- Collaborazione: in un team tutti devono capirsi senza domande superflue.
- Strumenti: formatter automatici e analizzatori di codice funzionano meglio se lo stile è uniforme.
2. Errori principali di stile del codice (e come evitarli)
Rientri e parentesi non coerenti
Errore:
Codice senza rientri e con parentesi caotiche è una tortura per occhi e cervello.
if(x>0){
System.out.println("x è positivo");
}else{
System.out.println("x non è positivo");
}
Come si fa:
if (x > 0) {
System.out.println("x è positivo");
} else {
System.out.println("x non è positivo");
}
Commento:
Usa quattro spazi per ogni livello di annidamento (è lo standard Java). La tabulazione è il male, a meno che tutto il team non abbia deciso diversamente.
Nomi sbagliati di variabili, metodi e classi
Errore:
int a = 5;
String s = "Vasya";
void f() { /* ... */ }
Come si fa:
int age = 5;
String userName = "Vasya";
void printReport() { /* ... */ }
Commento:
I nomi devono essere significativi e riflettere l’essenza della variabile o del metodo.
- Classi — iniziano con la maiuscola, CamelCase: UserAccount.
- Metodi e variabili — iniziano con la minuscola, camelCase: calculateSalary, userList.
Metodi e classi troppo lunghi
Errore:
Un metodo di 100 righe, una classe di 1000 righe — un vero nightmare mode per la manutenzione.
Come si fa:
Ogni metodo dovrebbe fare una sola cosa ed essere breve (idealmente — stare in una schermata). Anche le classi non dovrebbero crescere fino alle dimensioni di «Guerra e pace».
Esempio:
Male:
public void processOrder() {
// 200 righe di codice
}
Bene:
public void processOrder() {
validateOrder();
calculateTotal();
saveToDatabase();
sendEmailConfirmation();
}
Uso di «numeri magici» e stringhe
Errore:
if (status == 42) {
// ...
}
Come si fa:
public static final int STATUS_APPROVED = 42;
if (status == STATUS_APPROVED) {
// ...
}
Commento:
Invece di numeri e stringhe «magici» usa le costanti (static final). Nelle nuove versioni di Java ci sono anche gli enum — usali per insiemi limitati di valori.
Commenti: assenti o eccessivi
Errore 1:
Nessun commento — non è chiaro cosa faccia il codice complesso.
Errore 2:
Commenti per ogni azione, anche quelle ovvie.
// Incrementiamo x di 1
x = x + 1;
// Verifichiamo se x è uguale a 10
if (x == 10) {
// ...
}
Commenti del genere solo intralciano! Commenta solo i punti complessi o non ovvi. In generale, un buon codice dovrebbe essere comprensibile senza commenti — i commenti servono a spiegare il «perché», non il «cosa».
// Consideriamo lo sconto per i clienti VIP
double total = calculateTotalWithDiscount();
3. Convenzioni Java: come scrivono i professionisti
In Java esistono standard di formattazione ufficiali e de facto. Oracle Java Code Conventions e Google Java Style Guide — i più diffusi.
Rientri e parentesi
La graffa di apertura va sulla stessa riga della dichiarazione:
public void print() {
// ...
}
L’annidamento — quattro spazi.
Naming
- Classi e interfacce: CamelCase con iniziale maiuscola (Person, UserAccount).
- Metodi e variabili: camelCase con iniziale minuscola (calculateSalary, userList).
- Costanti: TUTTE_LE_MAIUSCOLE_CON_TRATTINO_BASSO (MAX_SIZE, DEFAULT_TIMEOUT).
- Package: solo lettere minuscole, possono essere separati da punti (com.example.project).
Spazi
Spazi intorno agli operatori e dopo le virgole:
int sum = a + b;
System.out.println(name, age);
Non mettere lo spazio dopo la parentesi aperta e prima di quella chiusa:
if (x > 0) { ... }
Lunghezza della riga
Si consiglia di non superare 100–120 caratteri per riga. (Sì, lo schermo è enorme, ma il codice si legge comunque meglio quando non va oltre l’orizzonte.)
Ordine di dichiarazione dei membri della classe
Ordine consigliato (secondo Oracle):
- Campi (prima statici, poi istanza)
- Costruttori
- Metodi
Esempio:
public class User {
private static int userCount;
private String name;
public User(String name) {
this.name = name;
userCount++;
}
public String getName() {
return name;
}
}
4. Esempio: refactoring di cattivo stile
Ecco un esempio di classe che potresti incontrare in natura:
class person{String n;int a;void p(){System.out.println(n+" "+a);}}
Da qualche parte in ufficio, uno sviluppatore Java piange per questo codice.
Miglioriamolo:
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public void print() {
System.out.println(name + " " + age);
}
}
Cosa è cambiato:
- Classe e membri con i modificatori di accesso corretti.
- Nomi significativi e leggibili.
- Ogni membro della classe su una nuova riga.
- Usato un costruttore per l’inizializzazione.
- Campi private per rispettare l’incapsulamento.
5. Dettagli utili
Formatter automatici
Le IDE moderne (IntelliJ IDEA, Eclipse, VS Code) possono formattare automaticamente il codice secondo lo standard.
Scorciatoie da tastiera:
- IntelliJ IDEA: Ctrl + Alt + L
- Eclipse: Ctrl + Shift + F
Analisi statica
Strumenti come Checkstyle, SonarLint e PMD aiutano a individuare violazioni di stile ed errori potenziali ancora prima di eseguire il programma.
Come si presenta:
- Checkstyle si lamenta se una variabile si chiama x invece di userAge.
- SonarLint segnalerà se un metodo è troppo lungo o una classe viola i principi SOLID.
Separazione delle responsabilità e «clean code»
- Ogni classe dovrebbe essere responsabile di un’unica cosa (Single Responsibility Principle).
- Non aver paura di creare classi e metodi aggiuntivi — non è «gonfiare» il codice, ma prendersi cura del lettore futuro.
- Cerca di evitare duplicazioni: se vedi due frammenti simili — estraili in un metodo separato.
Costanti e «numeri magici»: come fare bene
Invece di:
double price = 100 * 0.18;
Meglio:
public static final double VAT_RATE = 0.18;
double price = 100 * VAT_RATE;
E se hai set di valori fissi ricorrenti — usa gli enum:
public enum Status {
NEW, IN_PROGRESS, DONE
}
6. Errori tipici nello stile e nella leggibilità del codice
Errore n. 1: ignorare le code conventions.
Se nel team non c’è uno stile unico, il codice diventa rapidamente illeggibile e difficile da manutenere. Anche se scrivi da solo, tra un anno ti ringrazierai.
Errore n. 2: nomi troppo corti/lunghi.
Una variabile a o temp — male. Una variabile theCurrentUserNameThatIsUsedForAuthorizationInTheSystem — nemmeno. Trova un equilibrio: userName, age, bookList.
Errore n. 3: «numeri magici».
Inserire numeri e stringhe direttamente nel codice ostacola la manutenzione e aumenta la probabilità di errori.
Errore n. 4: metodi e classi enormi.
Più è grande un metodo, più è difficile testarlo e capirlo. Suddividilo in parti logiche.
Errore n. 5: struttura di classe scadente.
Campi sparsi ovunque, metodi dichiarati in ordine casuale — tutto ciò rende difficile trovare rapidamente ciò che serve.
Errore n. 6: commenti eccessivi o assenti.
Un commento «inizializzazione della variabile» accanto a int x = 0; non serve. Un commento che spiega una logica di business complessa — serve molto.
Errore n. 7: formattazione incoerente.
In una parte del progetto — quattro spazi, in un’altra — tabulazioni; qui le parentesi sulla nuova riga, lì sulla stessa riga. Sembra sciatto e infastidisce i colleghi.
GO TO FULL VERSION