Clean code – utilizzare nomi corretti

In questi giorni sto leggendo un libro molto interessante e a dir poco storico, parlo di “Clean Code – A handbook of Agile Software Craftsmanship
di Robert C. Martin.

In questo articolo voglio parlare del primo argomento che Uncle Bob tratta nel libro sopracitato, ovvero:  utilizziamo nomi significativi per variabili, funzioni, classi, etc…
Quante volte ci capita di scontrarci con del codice che utilizza nomenclature prive di significato ?? Quante volte noi stessi abbiamo utilizzato nomi senza senso ?? e quante volte poi ci siamo chiesti .. ma perchè ???!! .. è giunto il momento di cambiare marcia.

Prima di dare un nome a una variabile, le domande che dobbiamo farci sono le seguenti: perchè esiste? Cosa fa? Cosa rappresenta?

Se la varibile richiede l’utilizzo di un commento, esempio:

int d;  //indica il peso di un prodotto

allora c’è qualcosa che non va. Il tempo che sprechiamo per scrivere il commento, lo dovremmo impiegare per inventarci un nome significativo e se poi quel nome risulterà inconsistente, dovremmo cambiarlo e ricambiarlo finchè non sarà esaustivo (del resto con gli IDE di oggi giorno non ci vuole niente).

int pesoProdotto;

Dovremmo sempre cercare di tenere ben distinti i significati che assegnamo alle nostre entità. Evitiamo di utilizzare parole “rumorose”. Immaginiamoci di avere una classe Prodotti. Se creiamo altre due classi InfoProdotti e DatiProdotti, abbiamo dato due nomi differenti ad entità che non hanno un significato differente. Le parole “info” e “dati” sono solo rumore e danneggiano la leggibilità del nostro codice.

Evitiamo nomi impronunciabili. Siamo esseri umani e non leggeremo mai un libro composto da sole abbreviazioni e/o acronimi. Trasformiamo

private Date hms

in

private Date timestamp

potremo apparire meno sofisticati ma molto più furbi. La lunghezza del nome che sceglieremo dovrebbe essere proporzionale alla dimensione dello scope nel quale la varibile sarà utilizzata (immaginate la scomodità di utilizzare una variabile “i” in una funzione molto grande…e non dimentichiamoci che le funzioni non dovrebbero essere grandi :) .. ).

Evitiamo l’utilizzo dei prefissi e/o ornamenti vari. Non servono a niente!! Se dobbiamo scrivere un’interfaccia che astrae il concetto di form , non chiamiamola IShape ma Shape (salvo per vincoli imposti dal coding standard). L’utilizzatore non deve sapere che è un interfaccia ma solo che sta utilizzando una Shape. Evitiamo anche di utilizzare dei prefissi che rappresentano il contesto della classe (es: in un applicazione “Gas Station Deluxe” è una cattiva idea utilizzare il prefisso GSD per tutte le classi)

Vediamo ora come gestire i nomi delle classi, degli oggetti e dei metodi. Le due regole fondamentali che dobbiamo memorizzare nella nostra testa o marchiare a fuoco nel nostro petto (evitando incendi) sono:

  • Le classi e gli oggetti devono essere chiamate con un sostantivo o con una frase formata da sostantivi. Es: Customer, User, Logger
  • I metodi devo essere chiamati con dei verbi. Il metodo deve rappresentare un azione.  Es: deletePage, save, createPomodoro

Zio Bob, ci vieta anche di essere simpatici. Evitiamo di utilizzare nomi che abbiano uno spiccato senso dell’umorismo, in quanto sarebbero troppo legati alla nostra persona e di conseguenza potrebbero essere mal interpretati da altri.. questa cosa è un pò triste, ma pensandoci bene è vera. Se vogliamo cancellare un Items utilizziamo DeleteItems e non nomi come HolyHandBomb. Sinceramente non mi è mai capitato di vedere una cosa del genere.

Utilizziamo sempre una parola per ogni concetto. Potrebbe creare confusione l’utilizzo di tre parole differenti come fetch, retrieve e get per rappresentare un metodo che fa la stessa cosa su tre classi differenti.

Applicando queste semplici regole potrete migliorare la leggibilità del vostro codice.. che è cosa buona e giusta.

Questo articolo lo trovi sotto articoli e taggato come .

I commenti sono chiusi.