Chi controlla i controlli nel codice?

Non sempre giocare sulla difensiva paga.

E’ il caso dell’abuso di controlli e verifiche nel codice nonchè del loro impatto concreto su di esso.

Sono sempre più dell’idea che esista un qualche compromesso che garantisca una certo fiducia nel proprio codice senza forzare all’uso esteso/estensivo di verifiche, probe e altro (es: testare a ogni piè sospinto se tutte le variabili sono non-nulle).

Parlo di inserire dei controlli in modo accorto e misurato, senza eccedere in prassi assurde come tentare di “proteggere” ogni singola riga di codice o, peggio ancora, nell’inscatolare il corpo di intere funzioni dentro a blocchi try-catch.

Vero è che il supporto delle eccezioni non sempre è a regola d’arte e ci sono linguaggi così precisi (pedanti?) che generano tonnellate di eccezioni diverse, una per ogni tipo di condizione problematica. Ma questo non è mai una scusa valida per una loro gestione “pigra” e raffazzonata.

Personalmente sono dell’idea che:

1. un controllo in più non guasta se e solo se è dimostrabile che serve davvero a qualcosa (es: una correzione nota ad un problema ricorrente);
    
2. è inutile o comunque discutibile provare a catturare e gestire ogni errore/eccezione in un colpo solo (“Pokemon Exception Handling“?);
    
3. è stupido catturare errori/eccezioni per poi ignorarli (a meno che non si tratti di qualcosa veramente da ignorare come un warning ridicolo o stupido da parte di un compilatore, come questo);
    
4. meglio essere estremamente pedanti in fase di debug (assert, unit testing, programmazione difensiva a gogo …) e rimuovere i controlli ragionevolmente non più necessari in fase di release.

I bug sono ovunque!

Il quarto punto è quello che mi interessa di più ed è il motivo di questo post.

Rilasciare la versione di debug è sempre sconsigliabile tantopiù che di solito include controlli addizionali inseriti automaticamente nei binari dal compilatore (o chi per esso) più tutti i vostri, compresi quelli che potete ragionevolmente togliere.

Ad esempio verifiche pedanti sugli indici degli array, comodi in fase di debug per stanare eventuali “sforamenti” – tipo un off-by-one – e spesso inutili nelle versioni da rilasciare.

La parte rischiosa, tuttavia, è proprio la loro presenza.

Checchè se ne dica,

i controlli sono codice a tutti gli effetti e, come tale, soggetti essi stessi a bug, problemi di interazione col resto del codice, idiosincrasie, ecc…

Per questo è bene rimuoverli, se e quando hanno raggiunto il loro scopo.

Vige pur sempre la regola del “più roba c’è, più roba si può rompere” e stando a quel che dice Murphy, possiamo aggiungere “certamente lo farà“.

Immaginate che tristezza nel vedere il vostro programma fallire perchè vi siete dimenticati di togliere un controllo nella versione di rilascio e questo è “buggato“. Pensate sia un caso così raro e sfortunato da non meritare menzione? Sfortunatamente non è così.

Allo stesso modo abbondare con controlli precisissimi, perfino quelli apparentemente utili, può essere controproducente.

Ad esempio, tempo fa, mi son ritrovato con del codice che crashava in un blocco finally, all’atto di scrivere sullo stdout!

Questo per dire che i bug possono infilarsi ovunque, perfino dove ci si aspetterebbe di trovarli.

Da qui il titolo del post: “chi controlla i controlli?“

Che ne pensate?