Gabriele Lana

Qualche giorno fa Robert Martin come esercizio per imparare Clojure ha risolto il kata del bowling (da lui stesso ideato). Qualche programmatore più avvezzo al mondo funzionale ha cassato la soluzione ritenendola troppo “imperativa”, accusando non tanto Martin stesso quanto la presenza dei test :-D

L’argomentazione utilizzata per minimizzare l’utilità dei test è la semplicità dell’esercizio, al che ho pensato a come l’avrei risolto in Erlang, mi sono detto che “effettivamente la soluzione è semplice”, ho iniziato a scriverla provandola nella shell del linguaggio e subito ho provato un senso di fastidio

Continuavo a scrivere e riscrivere (va bhe, la shell ti da la possibilità di richiamare i comandi passati, ma il discorso non cambia) le stesse invocazioni verificando ad occhio il risultato, al che ho capito il senso di fastidio: che differenza c’è fra quello che stavo facendo e scrivere dei test unitari? Nessuna, tranne che i primi sono effimeri e non ti possono venire in aiuto quando sarai chiamato a fare refactoring. Quindi, amici dei linguaggi funzionali, perchè non vedete i test unitari come delle sessioni di interazione con la shell permanenti e automatiche?

Vi dirò di più, la soluzione che avevo inizialmente pensato era sbagliata :-) Dopo aver passato tutti i test che Martin aveva fatto nella presentazione di cui sopra, mi sono chiesto se potevo rompere il codice in qualche modo, ho visto che non erano coperti dei corner case, per esempio c’è la partita peggiore (tutti 0), ma non c’è la partita migliore (tutti strike), scrivo un test… e non passa :-)

Come vedete qui sotto, utilizzo una variabile per tenere il conto dei frame elaborati, inizialmente non lo facevo e nel caso di uno strike nell’ultimo frame, i due tiri di bonus successivi metchavano con la terza clausola e venivano considerati dei frame normali, quindi il “perfect game” che dovrebbe avere uno score di 300 aveva score 320

Alla fine ho guardato il codice e quella variabile arbitraria per contare il numero dei frame proprio non mi andava giù e senza cambiare i test sono arrivato a questa seconda soluzione

Che non mi piace perchè anche se rende più esplicito (forse anche più imperativo?) il conto dei frame, secondo me si capisce di meno, sopratutto non mi piace score_frame perchè si occupa sia di calcolare lo score di un frame (e fin qui), sia di selezionare i tiri rimanenti eliminando quelli del frame corrente

Cosa ne dite? Quale vi piace di più?