Errori

Quando un computer fa una cosa diversa da quello che ci aspettavamo diciamo "non funziona, c'è un errore". Ma non è così semplice.

Intanto: un programma "gira", cioè viene eseguito su una macchina fisica. Cloud o non cloud, alla fin fine sotto a tutto c'è dell'hardware: processori, memorie, fili. Hardware, in inglese, significa "ferramenta".

Il quale hardware, essendo regolato dalle leggi delle fisica, non può "sbagliare": può solo avere un comportamento che è spiegabile con una certa regola (fisica) invece di un'altra.

Ad esempio, quando un processore si surriscalda perché è stato caricato di troppi compiti contemporaneamente, non si è sbagliato: sta solo obbendendo ad una legge fisica precisa, quella che trasforma in calore il movimento di elettroni (l'effetto Joule).

Naturalmente chi ha progettato quella macchina, o chi ha progettato il programam che gestisce questi aspetti della macchina (si chiama "sistema operativo": Windows, Android, IoS, Linux, ...), avrebbe potuto e dovuto assicurarsi con un monitoraggio continuo della temperatura che quella situazione non si verificasse mai.

Se saliamo di livello, cioè dall'hardware passiamo al software, troviamo una situazione simile: un programma non fa mai una cosa sbagliata: fa quello che le regole dell'informatica gli permettono di fare. Se la gramamtica del linguaggio prevede che una variabile possa assumere un valore diverso da quello iniziale, allora questo evento può accadere; se invece non si può riassegnare un valore ad una variabile, o il tipo della variabile è definito una volta per tutto, allora il tentativo di cambiare valore produrrà un effetto diverso: il blocco di quell'istruzione, la notifica di violazione della regola o addirittura l'interruzione di tutto il programma. Tutto questo avviene secondo le regole del linguaggio e del suo interprete o compilatore.

Come per l'hardware, se il programma si comporta diversamente da come avevamo immaginato noi utenti (o noi programmatori) significa che il suo comportamente ha preso una strada diversa, ma che dal suo punto di vista non può che essere "giusta".

Gli errori peggiori non sono quelli che causano un blocco, ma quelli che non vìolano nessuna regola. Alcuni errori sono difficili da vedere perché si nascondono dietro l'apparenza di ovvietà. Un esempio molto molto citato nei manuali introduttivi alla programamzione è il seguente:

  1 x = 1;
  2 ...
  3 if (x = 1) {
  4   // do this action...
  5 } else {
  6   // do some other action...
  7 }

Sembra tutto chiaro: nella prima riga la variabile x viene portata al valore 1; poi - dopo un certo numero di altre istruzioni - nella riga 3 si controlla se x vale ancora 1, e in questo caso si esegue la riga 4. E in effetti sembra funzionare, perché viene eseguita la riga 4. Ma siamo sicuri? Proviamo a cambiare il valore di x:

  1 x = 0;
  2 ...
  3 if (x = 0) {
  4   // do this action...
  5 } else {
  6   // do some other action...
  7 }

Stavola la riga 4 non verrà mai eseguita, qualsiasi valore abbia assunto la variabile x alla riga 1. Questo perché l'operatore = in molti linguaggi di programmazione non serve a confrontare due valori, ma ad assegnare alla variabile di sinistra il valore che sta a destra. Ancora, il risultato di un'operazione di assegnazione di un valore ad una variabile è il valore stesso. In pratica (x = 1) vale 1 e (x = 0) vale 0. Ma siccome in certi linguaggi 0 può essere un modo per scrivere "false" l'espressione alla riga 3:

  if (x = 0)

restituirà sempre un valore falso.

Un altro errore classico, da principianti, è il seguente:

  for (c = 0; c<10; c++){
    c = c*2;
    // do this action...
  }

Qui l'idea del programmatore era ripetere un blocco dieci volte. L'espressione di controllo (quella tra parentesi tonde) del costrutto "for" aggiunge ogni volta 1 al contatore c, da 0 a 9. Si legge più o meno così: "per c che va da 0 a 9 con incrementi di 1...". Ma siccome c viene modificato all'interno del blocco (viene moltiplicato per 2), in realtà il codice del blocco verrà eseguito solo 4 volte. La prima volta c vale 0, la seconda vale 2, la terza 6 e la quarta 14. Siccome 14 è maggiore di 10, si ferma.

Insomma, i programmi hanno sempre ragione e i programmatori torto?

No. Ma trovare e correggere un errore non è affatto una cosa semplice, proprio perché si tratta di capire quale strada, tra tutte quelle possiibli, ha preso il flusso del programma. E' come un gigantesco flipper con una pallina che invece di seguire un certo percorso (quello immaginato e programmato) ne segue un altro, ugualmente possibile ma che non era stato previsto.

Si dice che in media nello sviluppo di un software di una certa complessità si passi il 30 % del tempo a scrivere il codice e il 70% a correggerlo, cioè a leggerlo, rileggerlo, rileggerlo...

E' anche per questo che è importante non solo quello che si scrive, ma anche come lo si scrive: ogni codice, non fosse altro che per essere corretto, verrà letto moltissime volte, da chi l'ha scritto ma anche da altri. Un codice incomprensibile è peggio di un codice errato.