[image]https://leganerd.com/wp-content/uploads/LEGANERD_040578.png[/image]

[image]https://leganerd.com/wp-content/uploads/LEGANERD_041520.png[/image]

Non appena iniziammo a programmare, scoprimmo con nostra sorpresa che ottenere programmi corretti non era cosi’ facile come avevamo pensato. Si dovette scoprire il debugging. Ricordo l’istante esatto in cui realizzai che gran parte della mia vita da allora in poi avrebbe dovuto essere spesa nella ricerca degli errori nei miei propri programmi. [Maurice Wilkes scopre il debugging, 1949]

L’avevo promesso a [url=https://leganerd.com/people/zed/]Zed[/url] ed io mantengo sempre le mie promesse [cit.]
Eccoci arrivati al [del]settantatreesimo[/del] quinto appuntamento con la rubrica [tag]ProPa[/tag], [b]Programmazione: Parliamone[/b]. Abbiamo finora sparlato e chiacchierato di cosa siano i linguaggi di programmazione, cosa li forma e come vengono trasformati perché la macchina li possa effettivamente leggere. No, non ti sto dicendo che [i]devi andare a leggere i precedenti episodi[/i]. Non [i]lo sto dicendo[/i]. No! Ma te lo ripeto! No! NO! Oh, va bene, cosa ti devo dire? Fai quello che ti pare: [i]leggiteli, analizzateli, studiateli, dormici insieme[/i]. E No, io non [i]sono un maestro dei messaggi subliminali[/i] [del]tu non hai visto niente[/del].
Ma partiamo dal principio.

[title]I bug: questi sconosciuti[/title]

“Come questi sconosciuti!?” vi starete chiedendo. Ebbene sì, [b]scordatevi[/b] tutto quello che avete sentito fino ad oggi, poiché solamente i veri programmatori hanno visto in faccia la morte per ben più di una volta e le leggende metropolitane, almeno per una volta, non sono neanche paragonabili alla verità. Come citato all’inizio dell’articolo, il tempo speso per eliminare questi “bachi” è per la maggior parte delle volte [b]decisamente superiore[/b] a quello utilizzato per creare il vero e proprio programma. Inoltre, il numero di errori presenti all’interno di un più o meno complesso software aumenta [b]esponenzialmente[/b] all’aumentare delle righe di codice; e sono assurdamente [b]riduttivo[/b].
Essi possono essere composti da errori [b]matematici[/b] ([i]divisioni per 0[/i], overflow e underflow aritmetici), errori [b]logici[/b] (cicli e ricorsività non voluti, valori booleani errati), errori di [b]sintassi[/b] (operatori sbagliati) e [b]molto[/b] altro ancora. Indipendentemente dal tipo di progetto, sono solitamente più o meno risolvibili ma, quando il codice inizia a diventare davvero [b]massiccio[/b], [i]milioni[/i] di righe, neanche un [b]dragone prismatico[/b] riesce più ad eliminare un bug senza crearne altri dieci. Infatti, nella quasi totalità dei casi, i programmi vengono rilasciati con alcuni bug già conosciuti ma irrisolti che però, teoricamente, non hanno lo sgradevole effetto di far implodere la macchina e che quindi possono convivere [b]temporaneamente[/b] con l’ecosistema software e hardware.

[title]Lo sfigato che tenta di risolvere i bug[/title]

Questi errori devono comunque essere [b]risolti[/b], poiché un buon programma deve funzionare appieno ed in [b]assenza[/b] di limitazioni. Arriviamo quindi alla tanto odiata fase di [b]debugging[/b]. E’ difficile spiegare come si possa arrivare a questa fase senza alcune basi di metodologie e sviluppo di software, però per il momento potete immaginare la fase di debugging in tre differenti fasi: la prima fase, può sembrare scontato ma non lo è affatto, avviene direttamente durante la scrittura del codice iniziale, dove vengono risolti i [b]primi errori[/b] mentali che il programmatore generalmente, in assenza di una pianificazione veramente completa ed articolata, trascrive e [b]riconosce[/b] senza fatica (inoltre, gli errori grammaticali vengono già evitati grazie al’azione del compilatore); la seconda fase è quella che porta i coder a proporre i software ai tester già direttamente dalle versioni instabili (alpha, beta, etc…) che aiutano a svelare bug critici che non permettono un adeguato funzionamento, per ottenere una release che raggiunga l’obiettivo [b]stabilito in partenza[/b]; la terza ed ultima fase è quella che, insieme alla [i]manteinance[/i], contribuisce a chiudere i bug più importanti e ad aprirne quasi sicuramente di nuovi a causa dell’azione di aggiornamento che i developer devono compiere se vogliono mantenere il programma up-to-date [Poi se il software è semplice, compie una sola operazione ed usa 1MB di RAM, lo si lascia così com’è e si passa ad altro!].
In tutte queste differenti fasi, la figura dello [b]sfigato debugger[/b] sale in superficie e diventa estremamente importante, se non determinante, per la buona riuscita del progetto. Il problema è che, essendo sfigato, il suo salario sarà sempre [i]proporzionalmente inverso[/i] al numero di bug risolti.

[title]Quando il gioco si fa duro, tutti iniziano a scappare[/title]

#define TRUE FALSE //Happy debugging suckers

Se il lavoro di debugging fosse così estremamente semplice, quasi [i]nessuno[/i] si sognerebbe di lamentarsi. Il fatto è che non è così dannatamente semplice poiché, si sa, noi nerd siamo anche un po’ bastard-inside e facciamo anche a gara per chi riesce a dimostrarsi tale in modo più spettacolare. I debugger sono ostacolati, nella maggior parte dei casi, dalla più o meno volontaria illeggibilità del codice che un programmatore produce. Esistono, infatti, programmatori cresciuti a [b]pane e Orwell[/b] che decidono di rendere il proprio codice [i]sporco e confusionario[/i] per [b]combattere[/b] un nemico che non esiste o a causa di quella vena di [i]sadismo[/i] che dopo ore di lavoro esce sempre fuori. Si narra addirittura, nelle più antiche leggende, che il [b]predatore naturale[/b] di queste stralunate bestie sia proprio il solitario, caffeinomane, notturno, programmatore addetto al mantenimento del codice che, utilizzando una serie di tecniche [i]zen[/i] (ed un po’ di [i]magia[/i]), riesce quasi sempre a trovare quello che sta cercando.
La maggior parte della magia è fatta dai [b]debugging tools[/b], programmi adibiti ad aiutare il programmatore a gestire gli errori, attraverso tecniche di[i] monitoraggio dell’esecuzione[/i], [i]della memoria[/i] (utlie soprattutto nei linguaggi di basso livello e nel C) e [i]dei cambiamenti di valore[/i]. Molto spesso, soprattutto per chi lavora anche in ambito [b]hardware[/b], i migliori amici diventano [i]l’oscilloscopio[/i], un macchinario per rilevare le onde ed i segnali, l'[i]analizzatore di stato logico[/i] ed il [i]simulatore di circuiti[/i].
Ovviamente, anche questi tool si stanno evolvendo e piano piano, grazie alla ricerca sulle AI, riusciranno sicuramente a migliorare drasticamente la vita di questi poveri lavoratori [del]o a distruggerli insieme a tutto il resto dell’umanità[/del].

[title]Quando il programmatore è simpatico e coccoloso[/title]

Starete dunque immaginando [del]ma sono sicuro di avervi sopravvalutato[/del] come un coder possa effettivamente aiutare a rendere più semplice e veloce questo[b] importantissimo[/b] processo.
Solitamente, si fa riferimento a delle tecniche che nel corso della storia sono diventate degli [b]standard[/b] entrando a far parte delle conoscenze richieste. Il programmatore deve sempre:

– [b]Utilizzare un sistema di indentazione[/b] che permetta di scorgere facilmente sistemi ad albero, funzioni e cicili. All’inizio del progetto, inoltre, se esso è costruito da vari developers, viene anche stabilita una [b]grandezza fissa dei tab[/b] (io per esempio preferisco il tab a tre spazi) per evitare confusioni od errori in fase di debugging. La tecnica principale prevede che si parta da [b]sinistra[/b] verso destra per creare questi livelli ma, in determinate occasioni, il sistema può essere anche invertito e fatto partire da [b]destra[/b] – ed in questo caso, si decide una lunghezza fissa per il [b]livello base[/b] e poi si cancella un tab per passare a quello successivo.

[image]https://leganerd.com/wp-content/uploads/LEGANERD_041519.png[/image]

– [b]Commentare![/b] Il commento è una delle parti del codice più importanti in assoluto, poiché permette al maintainer, o allo stesso autore del codice, di conoscerne i punti più [i]complessi ed oscuri[/i] e di poter capire il [b]come[/b] ed il [b]perché[/b] lavora in un determinato modo e situazione. Essi, per ora, [b]non vengono letti[/b] dal compilatore e servono esclusivamente agli esseri umani per poter lavorare più o meno serenamente senza essere afflitti da improbabili algoritmi ricorsivi che di standard non hanno neanche una lettera. Anche i commenti vengono impostati secondo una [i]tecnica[/i]: se per esempio ci troviamo davanti ad il codice [i][b]classe = StudentiMaschi + StudentiFemmine[/b][/i], il commento non deve essere un inutile [i]classe=studentimaschi+studentifemmina[/i] od un superfluo [i]la classe è composta da studenti maschi e studenti femmina[/i], bensì potrebbe essere [b]la definizione di classe è situata all’interno del file scuola.h[/b], in modo tale da fornire un ulteriore informazione che potrebbe essere essenziale in una fase successiva.

-[b]Utilizzare un sistema di notazione standard[/b]. Ultimo ma non meno importante requisito per diventare un piccolo programmatore è la conoscenza dei più frequenti modi di [b]nominare[/b] variabili, funzioni, constanti, etc. per avere una visione generale del programma più chiara a tutti i membri del team. Ne esistono vari ma, generalmente, esso viene [b]stabilito[/b] democraticamente dal team o dittatorialmente dal capogruppo e quindi può variare in infiniti modi. Possono essere citate la [i]notazione ungara[/i], la [i]convenzione CamelCase[/i] e la [i]notazione posizionale[/i].

Sfortunatamente, queste convenzioni non vengono sempre rispettate e sono molti i casi di programmi [b]illeggibili[/b] a causa di programmatori [i]malvagi[/i] persino all’interno del movimento Open Source, il quale da sempre ha l’obiettivo di rendere la vita dei debugger più semplice facendo in modo che tutti i programmatori imparino per una volta ad essere rispettosi dei propri colleghi.

Approfondimenti
– [url=http://en.wikipedia.org/wiki/Debugging]Debugging[/url]
– [url=http://it.wikipedia.org/wiki/Bug]Bug[/url]
– [url=http://it.wikipedia.org/wiki/Notazione_ungara]Notazione ungara[/url]
– [url=http://it.wikipedia.org/wiki/Ciclo_di_vita_del_software]Ciclo di vita del software[/url]
– [url=http://en.wikipedia.org/wiki/Debugger#List_of_debuggers]Lista di debugger (software) famosi[/url]
– [url=https://leganerd.com/tag/propa/]Precedenti articoli di Propa[/url]
[more]Anche questo è venuto lunghetto. Ci sarebbe TANTISSIMO da approfondire, ma questo non è davvero il luogo adatto (e sono sicuro che ci siano utenti, i sopraddetti “veri programmatori” molto più preparati di me). Per il resto enjoy! Per la prossima settimana sono sinceramente un po’ combattuto: Editor, WYSIWYG e IDE o descrizione di un linguaccio di programmazione? Mmm…[/more]