La sindrome APL…

Salve gente.

Qualche post fa ho affermato di apprezzare il codice sintetico e preciso.

Ho scritto sintetico ma non certo al limite dell’illeggibilità!

Chi non ha mai avuto la tentazione di far stare tutto su una sola o su poche righe, sperando/confidando in una qualche ulteriore ottimizzazione da parte del compilatore/interprete di turno?

Parliamo quindi di un’astrusa forma di ottimizzazione che non riguarda gli algoritmi che costituiscono un programma quanto piuttosto la loro codifica: si crede o spera cioè che risparmiando caratteri si ottenga un programma più snello e più performante.

Ovviamente non è sempre così…

La sindrome APL

Nel libro “Writing solid code“, Steve Maguire chiama questo atteggiamento “sindrome APL“, dal nome di un vecchio linguaggio di programmazione, famoso per essere tanto potente quanto estremamente conciso.

Da Wikipedia:

“Because of its condensed nature and non-standard characters, APL has sometimes been termed a ‘write-only language’, and reading an APL program can at first feel like decoding Egyptian hieroglyphics.“

Maguire si sofferma su questa “sindrome” presentandola in questi termini:

“I programmatori che non sanno come il codice C viene tradotto in codice macchina, tentano spesso di migliorare la qualità di quest’ultimo usando un C succinto. La loro idea è che utilizzando una minima quantità di C si dovrebbe ottenere una minima quantità di codice macchina. C’è effettivamente una relazione fra le dimensioni del vostro codice C e quelle del corrispondente codice macchina, ma questa correlazione finisce quando la applicate alle singole linee.“

Questa frase suona da monito: spesso ci si “accanisce” su poche singole righe, cercando di semplificarle o ridurle all’osso per poi ottenere risicati miglioramenti o, nel caso peggiore, peggioramenti nelle prestazioni. In altri termini, si tratta di tempo buttato a migliorare piccole porzioni di codice (migliorie locali) piuttosto che a rivedere e migliorare l’intero contesto in cui compaiono (migliorie globali).

La trattazione prosegue poi con una dimostrazione pratica, codice alla mano, che ad esempio l’(ab)uso dell’operatore ?: (by the way, esiste una differenza sintattica per questo operatore in C e C++ ) non garantisce automaticamente risultati migliori del “classico” if.

Anzi, in alcuni casi, tentare di condensare più righe di codice con ?: o con l’operatore logico || (si veda questo mio vecchio post) può perfino essere controproducente.

Il trafiletto termina con questo invito:

“Se soffrite della malattia ‘tutto in una riga’ (conosciuta anche come ‘sindrome APL‘) tramite la quale utilizzate costantemente espressioni bizzarre cercando di far stare il vostro codice C su una sola riga di sorgente, accomodatevi su una confortevole poltrona, fate un respiro profondo e cominciate a ripetere: ‘E’ possibile scrivere codice efficiente che occupi più di una riga. E’ possibile scrivere codice efficiente che occupi più di una riga…’”

L’esperienza insegna

Tempo fa ero solito cascare quotidianamente in questo genere di atteggiamento. Vedevo il codice degli esperti (o presunti tali) e lo confrontavo col mio e, soprattutto, col mio stile. Vedevo righe e righe di codice accorpate in poche e invidiamo la sinteticità di quei programatori. Ovviamente provavo ad imitarli, sperando di raggiungere la loro bravura prima o poi.

Poi ad un tratto ho notato un particolare.

Ogni volta che mi capitava di rileggere il loro codice, dovevo sempre “ritradurmelo” da zero, facendo quindi una doppia fatica: prima dovevo “decomprimere” e ricondurre il loro codice a qualcosa di mentalmente più maneggevole (es: “espandere” le linee con gli operatori ?: in canonici if), poi finalmente potevo concentrami e provare a capire cosa faceva quel codice.

L’ammirazione per quel tipo di codice “zippato” si è rapidamente trasformato in ripudio. Totale. Di lì il mio abbandono dello stile K&R, il mio obbligo delle parentesi ovunque, il mio rigore nell’indentazione, la pedanteria in certi contesti, l’evitare “shortcut” o espressioni insolite, ecc…

Per quanto questa mia scelta comporti normalmente più fatica del solito nello stendere codice, ho avuto qualche piccola soddisfazione. Ricordo un tizio, mi pare australiano, che una volta mi fece i complimenti per un programma che avevo scritto, nonostante fossi alle prime armi col C++ e commettessi errori a ripetizione (e ne faccio tuttora, ghghgh… ). Una sua frase in particolare mi colpì molto: “non ho mai letto codice C++ semplice come il tuo“.

Da quel momento ho compreso che era la strada giusta: se un tipo qualunque riesce a leggere rapidamente il mio codice e addirittura gli risulta facile correggermi, allora significa che ho fatto davvero centro!

Precisazione doverosa

Sì, è vero, mi trastullo (e vi disturbo) abitualmente con concetti ed oggetti intrinsecamente un po’ complessi (metaprogrammazione, lambda, …) però tento di mantenere il codice quanto più possibile leggibile. Compatto quando posso, leggibile sempre.

Insomma ho capito che essere sintetici non è la stessa cosa di essere concisi fino alla nausea e la leggibilità è sovrana. I compilatori moderni sono certamente più astuti di un programmatore-medio, quindi perchè rendersi la vita più difficile cercando improbabili micro-ottimizzazioni che portano solo a complicare le cose?

In conclusione…

Qualità algoritmica e leggibilità: il resto è solo (un pro-)forma!

Ciau!