Ciao, e benvenuto nell'ottava puntata di questo podcast. Nella scorsa abbiamo parlato di come leggere il codice degli altri. Oggi ribaltiamo la prospettiva e guardiamo l'altra faccia della stessa medaglia: come scrivere codice che gli altri possano leggere. Perché ogni volta che scrivi, stai scrivendo per qualcuno che dovrà capirlo dopo di te. E molto spesso, quel qualcuno sei tu, tra sei mesi.
Partiamo da un cambio di prospettiva che vale tutta la puntata. Da principianti, si pensa che scrivere bene significhi far funzionare il programma. È il minimo, ma non basta. Il codice non è solo istruzioni per la macchina: è anche un messaggio per le persone. Il computer eseguirebbe felicemente anche il codice più incomprensibile del mondo; sono gli esseri umani, quelli che avranno bisogno di leggerlo, a cui devi pensare. Scrivere codice chiaro è, prima di tutto, un atto di gentilezza verso chi verrà dopo.
E chi verrà dopo, ripeto, molto spesso sei tu. Questa è la cosa che fa scattare qualcosa in testa a chi comincia. Tu oggi hai tutto il contesto in mente, ricordi perché hai scritto le cose in quel modo. Ma tra qualche mese quel contesto sarà svanito, e ti ritroverai a fissare il tuo stesso codice chiedendoti cosa diavolo stessi pensando. Scrivere in modo chiaro significa fare un favore al te stesso del futuro.
Veniamo al concreto. La singola cosa più importante per un codice leggibile sono i nomi. I nomi che dai a variabili, funzioni e componenti sono il modo principale con cui il codice si spiega. Un nome buono racconta cosa contiene o cosa fa una cosa, senza bisogno di commenti. Chiamare una variabile "x" o "dato" non dice niente; chiamarla "prezzo totale" o "utente corrente" racconta una storia. Spendere qualche secondo in più per trovare il nome giusto è uno degli investimenti migliori che puoi fare.
Seconda cosa: la semplicità batte l'ingegnosità. C'è una tentazione, soprattutto quando si migliora, di scrivere codice furbo, compatto, che risolve tutto in una riga contorta di cui si va fieri. Resisti. Il codice intelligente in modo esibizionista è difficile da leggere e da correggere. Il codice davvero bravo è quello noioso, ovvio, che chiunque capisce al primo sguardo. La chiarezza non è meno sofisticata della furbizia: è più sofisticata, perché è più difficile da raggiungere.
Terza cosa: ogni pezzo di codice dovrebbe fare una cosa sola e farla bene. Le funzioni enormi, che fanno dieci cose insieme, sono un incubo da leggere e da modificare. Se spezzi il lavoro in parti piccole, ognuna con un nome chiaro e un solo compito, il codice diventa una serie di frasi leggibili invece di un muro indistinto. Un buon segnale è questo: se fai fatica a dare un nome a una funzione, forse sta facendo troppe cose.
Parliamo dei commenti, perché c'è un equivoco comune. Il commento migliore è quello che non serve, perché il codice si spiega da solo grazie a buoni nomi e a una struttura chiara. I commenti non servono a dire cosa fa il codice: quello dovrebbe dirtelo il codice stesso. Servono a dire perché. Perché hai fatto quella scelta strana, quale vincolo ti ha costretto, cosa avevi provato prima. Il perché non è visibile nel codice, e quello è oro per chi legge.
C'è poi una regola d'oro che li riassume tutti: la coerenza. Un progetto in cui ognuno scrive a modo suo, con stili diversi, è faticoso da leggere anche se ogni singolo pezzo è buono. Seguire lo stile già presente in un progetto, anche se non è esattamente il tuo preferito, vale più che imporre il tuo. La coerenza rende il codice prevedibile, e il codice prevedibile è codice che si legge in fretta. Molti team usano strumenti automatici che formattano tutto allo stesso modo, proprio per togliere di mezzo la questione.
Una piccola abitudine che cambia tutto: prima di considerare finito il tuo lavoro, rileggilo con gli occhi di chi non sa niente. Fingi di vederlo per la prima volta. I nomi si capiscono? La struttura è chiara? Un collega ci si raccapezzerebbe senza che tu glielo spieghi a voce? Questa rilettura, che costa pochi minuti, è ciò che separa il codice che funziona e basta dal codice di cui puoi andare fiero.
Per oggi ci fermiamo qui. Scrivere codice leggibile non è un vezzo estetico: è ciò che rende il tuo lavoro utile nel tempo, tuo e degli altri. Buoni nomi, semplicità al posto della furbizia, pezzi piccoli con un compito solo, commenti che spiegano il perché, coerenza, e una rilettura finale con occhi nuovi. Il codice si scrive una volta e si legge tante: scrivilo per chi legge. Nelle note trovi qualche spunto. Se questa puntata e la precedente ti sono state utili insieme, condividile. Grazie per l'ascolto, e ci sentiamo alla prossima.