Clean Code Lonest nelle piccole cose non una

Clean Code

«L'onestà nelle piccole cose non è una cosa da poco» «Dio è nei dettagli»

Manutenzione 80% del lavoro nello sviluppo di un software

Principi TPM (Total Productive Maintenance) • Organizzazione (sapere dove sono le cose) • Ordine (una porzione di codice dovrebbe essere dove aspetti di trovarla) • Pulizia (mantenere pulito non solo il codice ma anche la propria postazione di lavoro) • Standardizzazione (seguire degli standard all’interno del team) • Disciplina (riflettere frequentemente sul proprio lavoro ed essere disposto a cambiare)

Tipico ERRORE Abbandonare il codice in anticipo, non perchè abbiamo finito, ma perchè ci concentriamo più sull'aspetto esterno che sulla sostanza di cio’ che abbiamo realizzato.

Buona Programmazione • Uno stile di indentazione coerente è uno degli indicatori statisticamente più significativi della bassa densità dei bug. • Essere onesti con il codice, onesti con i colleghi sullo stato del nostro codice e, soprattutto, essere onesti con noi stessi riguardo al nostro codice. • Il re-factoring fa parte del concetto di «Done» .

«il codice non è mai perfetto»

Imparare a scrivere codice pulito è un duro lavoro. Richiede più della semplice conoscenza dei principi e dei modelli. Devi sudare su di esso. Devi esercitarti da solo e guardarti fallire.

Capitolo 1 Clean Code

La fine del codice Alcuni dicono che siamo vicini alla fine del codice. A breve verrà generato tutto il codice anzichè scritto. I programmatori semplicemente non saranno necessari perchè gli uomini d'affari genereranno programmi dalle specifiche. Tutto ci ò non ha senso! Non ci libereremo mai del codice, perchè il codice rappresenta i dettagli dei requisiti.

Alcuni sperano che un giorno scopriremo un modo per creare macchine in grado di fare cio’ che vogliamo invece di cio’ che diciamo. Questo non accadrà mai.

Bad Code killer app E’ stato il bad code che ha fatto fallire la compagnia

«Più tardi è uguale a mai»

Il costo totale di un pasticcio Mentre il casino cresce, la produttività della squadra continua a diminuire, asintoticamente avvicinandosi allo zero. Man mano che la produttività diminuisce, i manager fanno l'unica cosa che possono; aggiungono più personale al progetto nella speranza di aumentare la produttività. Ma questo nuovo staff non è esperto nel design del sistema. Cosi’ tutti fanno sempre più pasticci, portando la produttività sempre più verso zero.

Cos’è il Clean Code? Pensieri dei programmatori esperti

Bjarne Stroustrup Inventore di C ++ e autore di The C ++ Programming Language • Il clean code è piacevole da leggere. • Quando gli altri modificano il bad code, tendono a peggiorarlo. • Il clean code mostra una particolare attenzione ai dettagli. • Il clean code è focalizzato. Ogni funzione, ogni classe, ogni modulo espone un atteggiamento deciso e non inquinato dai dettagli circostanti.

Grady Booch Autore di Object Oriented Analysis e Design with Applications • Il clean code si legge come una prosa ben scritta. • Dovrebbe contenere solo cio’ che è necessario.

Dave Thomas Fondatore di OTI, padrino della strategia di Eclipse • Il clean code facilita le altre persone a migliorarlo. • Il codice, senza test, non è pulito. • Più piccolo è meglio.

Michael Feathers Autore di Working Effectively with Legacy Code • Il clean code sembra sempre che sia stato scritto da qualcuno con prudenza. • Non c'è nulla di ovvio che tu possa fare per migliorarlo.

Ron Jeffries Autore di Extreme Programming Installed e Extreme Programming Adventures in C # • L’ espressività include nomi significativi • Se degli oggetti o dei metodi stanno facendo più di una cosa occorre fare il refactoring di essi. • Duplicazione ridotta.

Ward Cunningham Inventore di Wiki, inventore di Fit, coinventore di e. Xtreme Programming, leader del pensiero OO, il padrino di tutti coloro che si preoccupano del codice. • Puoi chiamare beautiful code il codice quando fa sembrare che il linguaggio sia stato creato per il problema.

Siamo autori Il campo @author di Javadoc ci dice chi siamo. Siamo autori e una cosa sugli autori è che hanno lettori. In effetti, gli autori sono responsabili di comunicare bene con i loro lettori. Il rapporto tra tempo di lettura e scrittura è ben oltre 10 : 1. Percio’ rendere facile il codice da leggere, lo rende più facile scrivere.

La regola del boy scout Se tutti noi lasciassimo il nostro codice un po’ più pulito di quando lo controlliamo, il codice semplicemente non potrebbe decadere.

Capitolo 2 Meaningful Names

Usa nomi che rivelano l'intenzione • Scegliere buoni nomi richiede tempo ma risparmia più di quanto ci vuole. • Cambiare i nomi quando ne trovi di migliori. • Se un nome richiede un commento, il nome non rivela il suo intento.

Evitare la disinformazione • I programmatori devono evitare di lasciare indizi falsi che oscurano il significato del codice • Per esempio : Non fare riferimento a un raggruppamento di account come account. List a meno che non sia effettivamente una lista. La parola List indica qualcosa di specifico per i programmatori. Quindi account. Group , bunch. Of. Account o semplicemente account sarebbe meglio.

Creare differenze significative • Non è sufficiente aggiungere una serie di numeri anche se il compilatore è soddisfatto. • Per esempio: In che modo i programmatori di un ipotetico progetto dovrebbero sapere quale di queste funzioni chiamare? get. Active. Account(); get. Active. Accounts(); get. Active. Account. Info();

Usare nomi pronunciabili Il codice a destra è decisamente più pulito di quello a sinistra

Usare nomi ricercabili Nomi a lettere singole e costanti numeriche hanno un problema particolare in quanto non sono facili da individuare all’interno del codice.

Evitare codifiche e prefissi Ad esempio se voglio creare un’interfaccia per la costruzione di figure è meglio chiamarla Shape. Factory piuttosto di IShape. Factory. Io non voglio che i miei utenti sappiano che sto dando loro un'interfaccia. Voglio solo che sappiano che è una Shape. Factory

Nomi di classi e metodi • Un nome di classe non dovrebbe essere un verbo. • I metodi devono avere nomi di espressioni verbali come post. Payment, delete. Page o save. • Setters e Getters dovrebbero essere prefissati rispettivamente da set e get.

Aggiungere un contesto significativo

Capitolo 3 Functions

«La prima regola delle funzioni è che dovrebbero essere piccole. La seconda regola delle funzioni è che dovrebbero essere più piccole di cosi’»

Fare una cosa • Le funzioni dovrebbero fare una sola cosa. • Più precisamente tutti gli step dovrebbero appartenere ad un livello di astrazione. • Quindi una funzione dovrebbe eseguire solo i passaggi che si trovano ad un livello inferiore al nome di funzione utilizzato. • Un modo per sapere se una funzione sta facendo più di una cosa è che puoi estrarre un'altra funzione da essa.

Lettura del codice dall'alto verso il basso Il codice dovrebbe essere letto come una narrazione dall’alto verso il basso. Ogni funzione dovrebbe essere seguita da quelle al livello successivo di astrazione in modo che possiamo leggere il programma, discendendo di un livello di astrazione alla volta mentre leggiamo l'elenco delle funzioni.

Switch Lo switch puo’ essere tollerato se appare solo una volta per creare oggetti polimorfi nascosti dietro un'eredità

Argomenti di una funzione Il numero ideale di argomenti per una funzione è zero. Poi arriva uno, seguito da due. Tre argomenti dovrebbero essere evitati laddove possibile. Più di tre richiede una giustificazione molto speciale e comunque non dovrebbero essere usati.

Non avere effetti collaterali La tua funzione promette di fare una cosa, ma fa anche altre cose nascoste. Nell’esempio sotto l’effetto collaterale è la chiamata a Session. initialize().

Preferire le eccezioni ai codici di errore Se si utilizzano le eccezioni anziché i codici di errore, allora il codice che può produrre un errore può essere separato dal resto del codice rendendo il tutto più semplificato

Capitolo 4 Comments

I commenti non compensano il bad code Una delle motivazioni più comuni per scrivere commenti è il bad code. Scriviamo una porzione di codice e sappiamo che è disorganizzata. Quindi diciamo a noi stessi "Ooh, farei meglio a commentarlo!" No! Faresti meglio a pulirlo!

Commenti buoni Alcuni commenti sono necessari o utili. Tuttavia, l'unico commento veramente buono è il commento per cui hai trovato un modo per non scriverlo. • Commenti legali (dichiarazioni di copyright e di autore) • Commenti informativi (per fornire informazioni di base)

• Spiegazione degli intenti (informazioni utili sull'implementazione) • Una precisazione (tradurre il significato di parte del codice)

• Avvertimento sulle conseguenze • Commenti TODO (lavori che il programmatore pensa che dovrebbero essere fatti)

Commenti cattivi La maggior parte dei commenti rientra in questa categoria. Di solito sono scuse per codice scadente. • Commenti ridondanti

• Commenti obbligatori • Commenti di disturbo

• Commenti sulla parentesi graffa di chiusura • Codice commentato

Capitolo 5 Formatting

Lo scopo della formattazione Far funzionare un programma non è il primo ordine del giorno per uno sviluppatore professionista. La funzionalità che crei oggi ha buone possibilità di cambiare nel prossimo rilascio e la leggibilità del tuo codice avrà un profondo effetto su tutte le modifiche farai.

Formattazione verticale • Un programma dovrebbe avere un limite massimo di righe per file • I file di piccole dimensioni sono in genere più facili da comprendere rispetto ai file di grandi dimensioni.

Spaziatura verticale tra concetti Ogni linea rappresenta un’espressione e ogni gruppo di linee rappresenta un pensiero completo. Essi dovrebbero essere separati gli uni dagli altri con linee vuote.

Densità verticale Se la spaziatura separa i concetti, la densità verticale implica una stretta associazione. Si noti come i commenti nel Listing 53 interrompono l'associazione stretta delle due variabili di istanza.

Dichiarazione di variabili Le variabili dovrebbero essere dichiarate il più vicino possibile al loro utilizzo.

Variabili di istanza Le variabili di istanza, d'altra parte, dovrebbero essere dichiarate all'inizio della classe. Quindi si dovrebbe evitare di fare:

Funzioni Dipendenti Se una funzione chiama un'altra, la funzione chiamante dovrebbe essere sopra la funzione chiamata. Cio’ dà al programma un flusso naturale.

Formattazione orizzontale I programmatori preferiscono chiaramente le linee corte

Spaziatura e densità orizzontale Si dovrebbero circondare gli operatori di assegnamento con uno spazio bianco per accentuarli. Tuttavia, non si dovrebbero inserire spazi tra i nomi delle funzioni e l'apertura della parentesi. Gli argomenti all'interno pero’ vanno separati.

Allineamento orizzontale Questo tipo di allineamento non è utile. Ad esempio, nella lista delle dichiarazioni sei tentato a leggere la lista dei nomi delle variabili senza guardare i loro tipi.

Indentazione Senza indentazione, i programmi sarebbero praticamente illeggibili.

Regole del team Un team di sviluppatori dovrebbe essere d'accordo su un singolo stile di formattazione. Vogliamo che il software abbia uno stile coerente.

Capitolo 6 Objects and Data Structures

Astrazione dei dati • È buona norma non esporre i dettagli dei nostri dati. • È corretto esprimere i nostri dati in termini astratti. • L'opzione peggiore è aggiungere immediatamente getter e setter.

Anti-simmetria di strutture dati / oggetti • Il codice procedurale facilita l'aggiunta di nuove funzioni senza cambiare le strutture dati esistenti. Il codice OO, d'altra parte, semplifica l'aggiunta di nuove classi senza modificare le funzioni esistenti. • Il codice procedurale rende difficile aggiungere nuove strutture dati perche’ tutte le funzioni devono essere modificate. Il codice OO rende difficile aggiungere nuove funzioni perche’ tutte le classi devono essere cambiate.

Codice procedurale

Codice OO

Legge di Demetra Un modulo non dovrebbe conoscere le interiora degli oggetti che manipola. La Legge di Demetra dice che un metodo f di una classe. C dovrebbe solo chiamare i metodi di: • C • Un oggetto creato daf. • Un oggetto passato come argomento fa. • Un oggetto contenuto in una variabile di istanza di C.

Un metodo non dovrebbe richiamare metodi su oggetti restituiti da una qualsiasi delle funzioni consentite. Il codice seguente non rispetta la Legge di Demetra perche’ chiama la funzione get. Scratch. Dir () sul valore restituito da get. Options () e quindi chiama get. Absolute. Path () sul valore restituito da get. Scratch. Dir ().

Disastri ferroviari Codice del tipo dell’esempio precedente è definito disastro ferroviario perchè assomiglia a un gruppo di vagoni accoppiati. Una soluzione migliore è la seguente: In ogni caso, entrambi I due frammenti di codice non rispettano la Legge di Demetra

DTO (Data Transfer Objects) • Struttura dati con variabili pubbliche e senza funzioni. • Strutture molto utili quando si comunica con i database. • Convertono i dati grezzi di un database in oggetti nel codice dell'applicazione.

Bean I Bean hanno variabili private manipolate da getters e setters.

Record di attivazione • Sono forme speciali di DTO. • Sono strutture di dati con variabili pubbliche o gestite in maniera Bean. • In genere hanno metodi di navigazione come e find. • Tipicamente i record di attivazione sono traduzioni dirette da tabelle di database. save

Capitolo 7 Error Handling

«La gestione degli errori è importante, ma se oscura la logica, è sbagliata»

Utilizzare le eccezioni piuttosto che restituire codici di errore

Utilizzare le eccezioni piuttosto che restituire codici di errore

Dichiarazione try-catch-finally • Eseguendo codice nella porzione try stai affermando che l'esecuzione puo’ bloccarsi in qualsiasi momento. • Il catch deve mantenere il programma in uno stato consistente, non importa cosa succede nel try. • Il blocco finally viene eseguito a prescindere dal verificarsi di un'eccezione.

Definire nuove eccezioni

Preferire Eccezioni Unchecked Esempio che delucida la preferenza: Se si lancia un'eccezionecheckede il catch è tre livelli sopra, devi dichiarare quell'eccezione nella firma di ciascun metodo tra te e il catch. Cio’ significa che un cambiamento a basso livello del software puo’ forzare cambiamenti su molti livelli più alti.

Catturare eccezioni Unchecked

Fornire contesto con le eccezioni • In Java, è possibile ottenere uno stack trace di qualsiasi eccezione; tuttavia, cio’ non puo’ dirti l'intento dell'operazione che ha fallito. • Meglio creare messaggi di errore informativi.

Definire classi di eccezioni in termini di esigenze del chiamante Senza wrapper

Definire classi di eccezioni in termini di esigenze del chiamante Senza wrapper Con wrapper

Non restituire null

In questo caso, get. Employees puo’ restituire null, ma deve? E’ possibile cambiare get. Employee in modo tale che restituisca una lista vuota:

Non passare null Restituire null da un metodo è brutto, ma passare null come parametro attuale è peggio. Passando null come argomento avremmo una Null. Pointer. Exception

Capitolo 8 Boundaries

Utilizzo del codice di terze parti • I fornitori di pacchetti e framework di terze parti si sforzano di ottenere un'ampia applicabilità in modo tale da attirare un vasto pubblico. • Gli utenti, d'altra parte, voglio un'interfaccia focalizzata sulle loro particolari esigenze.

Java. util. Map

Generics Senza Con

Alternativa senza generics Il casting e la gestione dei tipi vengono amministrati all'interno della classe Sensors.

Imparare il codice di terze parti • Imparare il codice di terze parti è difficile. • Anche la sua integrazione lo è. • Percio’ è buona norma scrivere alcuni test (chiamati test di apprendimento) per comprenderlo al meglio.

Test di apprendimento • I test di apprendimento non costano nulla. • Non solo i test di apprendimento sono gratuiti, hanno un ritorno positivo sull'investimento. • I test di apprendimento verificano che i pacchetti di terze parti che stiamo utilizzando funzionano come noi ci aspettiamo che lo facciano.

Capitolo 9 Unit Tests

TDD Test Driven Development TDD ci chiede di scrivere gli unit test prima di scrivere il codice di produzione. Ma questa regola è solo la punta dell'iceberg.

Le tre leggi del TDD 1) Non si deve scrivere codice fino a quando non si è scritto unit test che fallisce.

Le tre leggi del TDD 1) Non si deve scrivere codice fino a quando non si è scritto unit test che fallisce. 2) Non si deve scrivere più di uno unit test di quanto sia sufficiente per fallire.

Le tre leggi del TDD 1) Non si deve scrivere codice fino a quando non si è scritto unit test che fallisce. 2) Non si deve scrivere più di uno unit test di quanto sia sufficiente per fallire. 3) Non si deve scrivere più codice di quanto sia sufficiente per superare il test attualmente non funzionante.

«Avere test non puliti equivale a, se non peggio che, non averli»

Mantenere i test puliti • I test devono cambiare come il codice si evolve. • Più sporchi sono i test, più è difficile cambiarli. • Modificando il codice, i test precedenti iniziano a fallire. • Il caos nel codice di test rende difficile far passare nuovamente quei test.

Test puliti • Cosa rende un test pulito? Tre cose. Leggibilità, leggibilità e leggibilità. • Che cosa rende i test leggibili? La stessa cosa che rende leggibile il codice: chiarezza, semplicità e densità di espressione.

BUILD-OPERATE-CHECK pattern

Un assert per test • Ogni funzione di un JUnit test dovrebbe avere un solo assert.

Un assert per test • Ogni funzione di un JUnit test dovrebbe avere un solo assert. • Questi test arrivano a una singola conclusione che è veloce e facile da capire.

Un assert per test • Ogni funzione di un JUnit test dovrebbe avere un solo assert. • Questi test arrivano a una singola conclusione che è veloce e facile da capire. • il numero di assert in un test dovrebbe essere ridotto al minimo.

Singolo concetto per test • E’ buona norma testare un singolo concetto in ogni test. • Si dovrebbe minimizzare il numero di assert per concetto e testare un solo concetto per test.

F. I. R. S. T. I test puliti seguono cinque regole che formano l'acronimo • Fast: I test dovrebbero essere veloci.

F. I. R. S. T. I test puliti seguono cinque regole che formano l'acronimo • Fast: I test dovrebbero essere veloci. • Independent : I test non dovrebbero dipendere l'uno dall'altro.

F. I. R. S. T. I test puliti seguono cinque regole che formano l'acronimo • Fast: I test dovrebbero essere veloci. • Independent : I test non dovrebbero dipendere l'uno dall'altro. • Repeatable: I test dovrebbero essere ripetibili in qualsiasi ambiente.

F. I. R. S. T. I test puliti seguono cinque regole che formano l'acronimo • Fast: I test dovrebbero essere veloci. • Independent : I test non dovrebbero dipendere l'uno dall'altro. • Repeatable: I test dovrebbero essere ripetibili in qualsiasi ambiente. • Self-Validating: I test dovrebbero avere un output booleano. O passano o falliscono.

F. I. R. S. T. I test puliti seguono cinque regole che formano l'acronimo • Fast: I test dovrebbero essere veloci. • Independent : I test non dovrebbero dipendere l'uno dall'altro. • Repeatable: I test dovrebbero essere ripetibili in qualsiasi ambiente. • Self-Validating: I test dovrebbero avere un output booleano. O passano o falliscono. • Timely: I test devono essere scritti in modo tempestivo.

Andrea Caglio caglio@intre. it