Damian Conway
Perl Best Practices

O'Reilly - 2005 - 39.95 $
ISBN:0-596-00173-8

Recensioni di Daniele Radogna e Stefano Rodighiero.
© 2003 Perl Mongers Italia. Tutti i diritti riservati.

Recensione di Daniele Radogna [Voto:5/5]

Avendo veramente apprezzato Object Oriented Perl, OOP da qui in poi, attendevo una nuova pubblicazione di Damian Conway con una trepidazione appena leggermente inferiore a quella con cui alcuni di noi attenderebbero la scoperta di manoscritti perduti di Douglas Adams sulla Vita, L'Universo e Tutto Quanto. Il libro mi ha talmente spiazzato che ho dovuto scriverne una recensione per cercare di scoprire che cosa ne penso veramente. Questa recensione è la testimonianza di questo processo di autoanalisi.

Nutrito dalle aspettative suscitate da OOP, capace di chiarire realmente l'implementazione della programmazione a oggetti in Perl, e quindi dando un contributo importante alla comprensione di cosa il Perl sia e cosa possa fare, scoprire che al capitolo due di Perl Best Practice, PBP da qui in poi, alla voce bracketing, sono state spese due pagine per stabilire se sia meglio mettere le parentesi alla K&R (Kernighan & Ritchie, non offenderò nessuno cercando di ricordare chi siano) o alla BSD, mi ha procurato un leggero ma persistente shock. Giusto per capirci, la questione sviscerata è se sia meglio mettere la parentesi (parentesi tonda oppure quelle che in inglese si dicono braces, parentesi di apertura/chiusura blocco) sulla prima riga successiva all'istruzione che precede il blocco (BSD) oppure sulla medesima riga (K&R). Non svelerò la ragione di questa prescrizione per non ammazzare la suspence che indubbiamente non mancherà di attanagliare i lettori più pensosi. Analogamente, le rigorose prescrizioni nel merito della lunghezza delle linee di testo (78 caratteri) che seguono subito dopo ed una accurata analisi di quanti spazi è bene indentare il testo per agevolarne la leggibilità, lo, confesso, mi hanno fatto veramente temere il peggio. Dov'erano finite le illuminazioni che hanno animato le pagine di OOPS (si veda "blessing other things" in caso di dubbi)?

La risposta è che l'obiettivo di Conway non è quello di comunicarci finezze capaci di appagare la nostra libido computandi oppure di farci sentire molto intelligenti (anche perché sembra che Mark Jason Dominus, per sua esplicita ammissione, sia uno dei rarissimi casi in cui la fluenza in Perl abbia fatto colpo su qualche ragazza: si veda "A note about the cover" High Order Perl), ma vuole invece fornire al lettore specifiche per la stesura di codice perl che mettano in condizione di produrre software in modo più professionale e con maggiore qualità. Si intende qui come qualità quella che può apprezzare un manutentore del codice (che potrebbe essere una vostra istanza di qualche giorno posteriore): leggibilità, manutenibilità, riusabilità, secondo quanto recitano tutti i mantra del software engineering. Sebbene la sovraspecificazione (si dice così?) possa avere controindicazioni e provocare effetti collaterali sotto forma di leggere dispnee se si è in ambiti aziendali già di per se sovrastrutturati, tuttavia il testo di Conway persegue un obiettivo coerente che vuole intervenire sulla polvere che potrebbe essersi depositata sotto alcuni riposti ed acconci tappetini di qualche sviluppatore. Ovvero: Conway non vuole arricchire la vostra intuizione o conoscenza del Perl (o non più di tanto): vuole migliorare come scrivete codice Perl, il vostro *processo* per dirla aziendalmente. Se è consentita un po' di ironia da parte di un perlista convinto, suppongo che per ottenere questo risultato ci volessero le maniere forti, ed ecco probabilmente il perché dell'apertura del volume con le prescrizioni sulle parentesi.

Amplifichiamo. Una scorsa all'indice ci dice solo apparentemente quali sono i temi: code layout; naming conventions; values and expressions; variables; control structures; documentation; built-in functions; subroutines; I/O; references; regular expressions; error handling; command-line processing; objects; class hierarchies; modules; testing and debugging; miscellanea. Code layout e specialmente naming conventions, con tutta probabilità, sono i soli indizi del fatto che il testo non è un "normale" testo di Perl a cui siamo abituati - anche se il secondo titolo potrebbe provocare un involontario sussulto in chi, come riflesso condizionato à la Pavlov, sia molestato da un qualche ricordo a proposito della Hungarian Notation. Il vero tema diventa invece evidente da alcuni paragrafi; cito ad esempio: ambiguous abbreviations; ambiguous names; unnecessary subscripting; list processing side effects; ogni istanza del termine "documentation"; homonyms; lazy flags. Eccetera. Il testo è strutturato catechisticamente: le unità base di senso sono precetti (piuttosto lapidari, peraltro): fai questo / non fare quello, a cui segue il commento che indaga e da ragione del precetto, tecnica che ha antecedenti illustri nella letteratura religiosa di tutti i popoli.

Il testo è chiaro, preciso e ha il merito di mettere il lettore di fronte a un problema: prendere posizione di fronte alla necessità indicata dall'autore, ovvero operare scelte consapevoli in funzione di una gestione professionale del proprio modo di stendere codice. Per dirla diversamente: questo libro non si rivolge a voi che scrivete Perl: si rivolge a voi che vi guardate scrivere codice Perl. Altrimenti: questo non è un testo sulla tecnologia del Perl, è un testo sulla pratica del Perl.

Se da un lato l'applicazione acritica e in toto dei comandamenti - oops - delle regole indicate può in alcuni casi risultare francamente discutibile (mi viene in mente un qualche recensore che, entusiasticamente, menziona il fatto che il testo costituisce il "Department coding standards, period"), d'altro canto i coding standard sono necessari anche se si scrive codice in totale solitudine, appena che il codice debba essere consegnato a un cliente. Stabilito quindi che i coding standards stanno al software engineering come i litigi ai matrimoni (ricordate? troppi litigi avvelenano la convivenza; l'assenza di litigi porta alla noia; ergo esiste un numero ottimale di litigi), e postulato il fatto che voi vogliate migliorare il vostro modo di gestire la stesura del codice, la domanda cui rimane da dare risposta è se questo testo risponda a questo diverso tipo di aspettative. In parole povere, vale la pena di arricchire la vostra biblioteca con questo libro?

La riposta dipende in modo essenziale A) da chi siete voi ma anche - sorpresa - B) in quanti siete voi. Come sviluppatore individuale, caso A), ovvero come singolo programmatore, il testo presuppone che il vostro viaggio nel mondo del Perl abbia superato la fase eroica (quale sia stata la sua durata) e siate entrati in quella maturità che prevede, auspicabilmente, una discreta padronanza delle tecniche ma soprattutto una esperienza o una sensibilità professionale che vi abbia portato a capire cosa c'è realmente alla base di un solido mestiere come programmatore, il che non è correlato necessariamente con la capacità di scrivere codice particolarmente geniale (si veda l'aforisma: "Don' be clever" a pag. 453). Come team (caso B)) Conway presuppone che siate per l'appunto un team e quindi che sia vostro interesse concordare un insieme di regole che vi impediscano di litigare a morte tra di voi e/o di chiudere l'azienda, generalmente in quest'ordine. In entrambi i casi Conway vi fornisce un repertorio di precetti e istruzioni che, recepito con intelligenza, senza sottrarsi al compito di una propria valutazione e verifica, è senz'altro utile e spendibile, nonché punteggiato qui e là da informazioni e suggerimenti assai interessanti. Quanta parte di questo repertorio effettivamente entrerà poi nel parco delle vostre tecniche e faccia al caso vostro, stante la professionalità del testo e la indubbia qualità della scrittura e della esposizione, non è facile dire perché ciò dipende dal vostro grado di maturazione come software engineer, dal vostro grado di disciplina, dal fatto che abbiate già idee estremamente chiare su come dovete gestire il processo di software coding: se vi chiamate Steve Mc Connell, Andrew Hunt o David Thomas questo testo potrebbe avere un impatto piuttosto limitato sulla vostra vita. Tuttavia l'autore di questa modesta recensione è a sua volta uno di coloro convinti che, forse, la fama del perl come "executable line noise" è dovuta più ai perlisti che al Perl e che una maggiore attenzione agli aspetti meno divertenti ma decisamente più sostanziali della stesura del codice può far crescere numero e qualità delle soluzioni Perl che fanno contenti gli utenti - e quindi, in ultima analisi, la comunità dei perlisti. In questo senso PBP fornisce una serie di strumenti e occasioni di riflessione da accogliersi positivamente e come opportunità da non trascurare, anche se, come detto, alcuni precetti sono alquanto opinabili.

Vorrei aggiungere che il testo del Conway ha una caratteristica che me lo rende particolarmente simpatico: è un testo anti-ego. Ovvero, è un libro che privilegia la formazione di un solido, onesto mestiere a scapito della tentazioni di quel ramo della programmazione che fa parte della Apocalittica, ovevro in cui la realizzazione di codice è lo strumento di elezione per la rivelazione al resto del mondo della propria intelligenza (altresì noto come Primadonna Programming). Per questa ragione, nell'approccio al libro, invito a usare una tecnica inversa a quella dell'assunzione di alcuni medicinali: usare bene prima di agitarsi, perché pur mantenenendo, come detto, alcune riserve su certe paragrafi, tuttavia questo libro merita attenzione e una buona sintonia (e potrebbe non essere facile per tutti).

Concludo con una osservazione. Quella parte di software engineering attinente il processo di coding è sempre stato focalizzato su team che sviluppano con linguaggi considerati tradizionalmente di system programming: C, C++, Java, ADA, eccetera, all'interno dei quali team il Perl poteva svolgere una funzione ancillare, sia di prototipazione rapida che di proof of concept che di tecnologia per la verifica della applicazione dei coding standard o l'estrazione di metriche. L'ultimo sforzo di Conway invece sposta l'enfasi indicando chiaramente la necessità e la possibilità di utilizzare queste metodologie in applicazioni sviluppate con un linguaggio di scripting per eccellenza. Da quel poco che so di Conway, questo più che un suo auspicio mi sembra un dato di fatto presente in realtà fuori dall'Italia. Sarebbe interessante capire più a fondo l'esperienza di chi sviluppa Perl in Italia alla luce di questa affermazione.


Recensione di Stefano Rodighiero [Voto:5/5]

Potrei cavarmela dicendo che Damian Conway non ha bisogno di presentazioni, e molto probabilmente direi la verità, ma io voglio spendere due parole lo stesso.

Programmatore prolifico: i suoi contributi su CPAN vanno dal puro divertissement (Coy.pm, per dirne uno) al modulo utilissimo se non fondamentale (Parse::RecDescent, Class::MultiMethods, NEXT). "And everything in between", come si dice (Quantum::Superpositions, ad esempio).

Come divulgatore e oratore non ho esperienza diretta, ma tutti i resoconti che ho letto parlano di robusta competenza, chiarezza, verve irresistibile e capacità di collegamenti logici da togliere il fiato.

Infine, autore di libri. Finora però Conway poteva vantare soltanto - si fa per dire - l'ottimo "Object Oriented Perl", di cui potete leggere su Perl.it. Finora.

"Perl Best Practices" è costituito da una collezione di 256 suggerimenti pratici per scrivere codice al meglio in Perl. Sono suddivisi per temi, e ciascuno è accompagnato da un ampio commento, che spiega le ragioni del suggerimento e i motivi che dovrebbero spingere a scartare scelte differenti.

Damian Conway (lo si legge nella prefazione) non pretende che i suoi suggerimenti abbiano validità universale. Dice però altre due cose, più deboli ma secondo me più significative.

Primo. I 256 consigli sono tra loro consistenti: idealmente si può decidere di adottarli tutti, senza che entrino in conflitto con loro.

Secondo. Conway spiega che anche se i suggerimenti non vengono adottati, il solo riflettere sugli argomenti presentati, e decidere per l'una o per l'altra pratica, è di per sé un utilissimo percorso di miglioramento.

Aver parlato di percorsi mi suggerisce un altro commento su un aspetto del libro che mi è molto piaciuto: si può leggere il testo da cima a fondo, riflettendo su ciascun punto e seguendo la zoomata all'indietro proposta da Conway (dall'indentazione al design OOP, grosso modo: per i fatti specifici che riguardano l'indice rimando alla pagina web del libro). Ma PBP è anche un libro che si può leggere come un breviario, piluccando a casaccio, oppure usandolo come riferimento quando non si è certi del proprio stile.

In Perl il TIMTOWTDI è stato talvolta preso come scusante per generare mostri, e ha indirettamente causato la cattiva fama del linguaggio. In "Perl Best Practices" Conway pone come obbiettivi robustezza, efficienza e manutenibilità, e per perseguirli non esita in qualche caso a proporre l'abbandono totale di certe feature di Perl: le keyword unless e until, ad esempio, oppure le pseudohash.

È qui che sta la rilevanza di "Perl Best Practices": le 256 raccomandazioni di Conway non solo soltanto i preziosi consigli di un programmatore più esperto, ma anche una documentata e articolata indicazione del fatto che Perl, con i dovuti accorgimenti, può essere uno strumento di sviluppo efficace per l'industria IT.

A questo punto dovrei scrivere un paragrafo spiegando a chi è adatto il libro, e a chi non è adatto. A dirla tutta, mi sembrerebbe molto più equo se foste voi a scrivere a me spiegandomi i motivi per cui non acquistereste questo libro.

A parte gli scherzi, prendiamo in esame il tipico novero di categorie utilizzatrici di Perl: gli amministratori di sistema, coloro che usano Perl come una bash avanzata, possono magari indirizzarsi ad altro (ma perderebbero capitolo interessanti sull'uso di espressioni regolari, sull'I/O, sull'interazione con la linea di comando...).

Chi si accinge a studiare il linguaggio potrebbe magari posticipare l'acquisto dopo la lettura di un testo introduttivo, in maniera tale da preparare il terreno alla ricezione dei consigli di Conway. Tutti gli altri, coloro cioè che scrivono codice per divertimento o (soprattutto) per lavoro, secondo me dovrebbero fare un pensiero sull'acquisto del libro.

PRO

  • Taglio estremamente pratico
  • Appendice sulla configurazione degli editor (non lunga, ma un punto di partenza)
  • Appendice con un elenco dei moduli (core e non) raccomandati
  • Stile chiaro e piacevole

CONTRO

  • È un peccato che l'Appendice B, che riassume tutti i 256 consigli, non abbia un'indicazione del numero della pagina dove quel consiglio viene spiegato