Clean Code, Objects

Scegliere i nomi è un’ardua impresa. Eccoci ancora a parlare di “Clean Code”, l’argomento di questo articolo sarà: il nome degli object.

17 lug 2017

Scegliere i nomi è un’ardua impresa

 

Eccoci ancora a parlare di “Clean Code”, l’argomento di questo articolo sarà: il nome degli object.

 

Appena iniziata la mia esperienza lavorativa qualcuno mi disse: “la cosa più difficile in informatica è dare i nomi…”.

 

Denominare in modo coerente gli “attori della vostra commedia” (siano essi classi, variabili, ecc..) non è impresa facile:

 

fino a che ci si limita a chiamare le variabili a e b tutto è facile ma, a lungo andare, si creano problemi non banali.

 

Prendiamo ad esempio il seguente codice:

 

public List<int[]> getThem() {

  List<int[]> list1 = new ArrayList<int[]>();

  for (int[] x : theList)

    if (x[0] == 4)

      list1.add(x);

  return list1;

}

 

 

Questo breve metodo sembra molto semplice e banale, ma quanti di voi sanno dirmi a prima vista cosa fa esattamente?

 

 <<Dalla proprietà “theList” prende tutti gli elementi che hanno il valore 4 in posizione 0…>>

Sarebbe tutto bello se non fosse che…non si capisce assolutamente niente, ed è tutta colpa dei nomi!

 

Guardando questo codice mi vengono in mente un po’ di domande, partendo dalla prima riga:

  • un metodo che si chiama “getThem” cosa mi torna? devo per forza leggere il corpo del metodo per capire cosa fa.
  • la lista che si chiama “list1” cosa può contenere? devo per forza leggere il corpo del metodo per capire cosa conterrà.
  • la priorietà “theList” cosa contiene? per capire la risposta devo addirittura leggere codice che non fa parte di questo metodo!
  • perchè prendo il valore in posizione 0? cosa rappresenta la posizione 0? anche per capire questa risposta devo leggere codice che non fa parte del metodo.
  • perchè prendo il valore 4? cosa rappresenta? …ci siamo capiti.

 

Insomma questo metodo non parla! lo devo leggere sempre per forza tutto e addirittura a volte non basta!

 

Se dovessi fare refactoring (cambiando solo i nomi degli object) il metodo diventerebbe:

 

public List<int[]> getFlaggedCells() {

  List<int[]> flaggedCells = new ArrayList<int[]>();

    for (int[] cell : gameBoard)

      if (cell[STATUS_VALUE] == FLAGGED)

        flaggedCells.add(cell);

    return flaggedCells;

}

 

  • getThem diventa getFlaggedCells – un metodo che si chiama getFlaggedCells cosa potrà mai fare? prendere le celle flaggate, ovvio!
  • list1 diventa flaggedCells – direi nessun commento necessario per questa modifica
  • x diventa cell – le operazioni fatte con “x” erano molto poche quindi anche “x” si capiva ma siccome siamo bravi rinominiamo anche quello
  • theList diventa gameBoard – interessante! cominciamo a capire anche il contesto in cui il metodo vive: prima non era minimamente possibile!
  • 0 diventa STATUS_VALUE – in questo caso è stata utilizzata una costante che ci aiuta a rendere più esplicativo cosa rappresenta 0 (un po’ come se rinominassi 0 con STATUS_VALUE)
  • 4 diventa FLAGGED – come sopra.

 

 

Proviamo a mettere a confronto cosa fanno le due versioni del metodo:

la prima – Dalla proprietà theList prendo tutti gli elementi che hanno il valore 4 in posizione 0

la seconda – Dalla board prendo tutte le celle flaggate.

 

 

Qual’è la versione migliore secondo voi?

 

Vi lascio con un paio di ultimi consigli:

 

  • Evitate i nomi molto lunghi – i nomi devono spiegare cosa stanno rappresentando con il minimo numero di parole
  • Utilizzare nomi pronunciabili – aiuta molto la lettura (non usare GenDat ma GenerationDate)
  • Per nominare le Classi utilzzare i sostantivi
  • Per nominare i Metodi utilizzare i verbi
  • Usare sempre le stesse “KeyWord” – se uso Get per le ricerche tutti i metodi che cercano si devono chiamare Get, non Find non Search ma Get, questa è una buona convention da definire a livello di team! (vedi articolo precedente).

 

 

Direi che per questo articolo vi ho annoiato abbastanza quindi Good Coding, alla prossima!