Come scrivo codice dopo quarant'anni di errori

Programmo dai primi anni Ottanta. Molte delle abitudini con cui ancora oggi scrivo codice non me le sono inventate: arrivano dai listati dell'epoca, dai libri sull'assembler, dai linguaggi che ho usato e da migliaia di errori fatti nel frattempo.

In TEA: un assembler residente per 8080, un libro di codice per 8080, il sorgente assembler era disposto sulla pagina in modo estremamente regolare. Codice e commenti occupavano spazi distinti, le strutture erano riconoscibili anche geometricamente. Molti anni dopo, con ambienti come Visual Basic, continuava a essere naturale pensare al programma anche come a qualcosa che si dispone nello spazio.

Oggi una parte sempre maggiore del codice può essere scritta da un'intelligenza artificiale. Si potrebbe pensare che queste attenzioni abbiano perso importanza.

A me sembra il contrario.

Dire «ormai il codice lo scrive l'IA, quindi non importa più saperlo scrivere» somiglia molto a dire «esiste la calcolatrice, quindi non serve più saper fare i conti». La calcolatrice ha eliminato una parte del lavoro meccanico; non ha eliminato la necessità di accorgersi che 17 × 23 non può fare 8.941.

Come scrivo

Una funzione molto semplice, scritta in una forma comune, potrebbe essere:

// Somma i valori positivi
function somma_positivi($valori) {
    $somma = 0;
    foreach ($valori as $valore) {
        if ($valore > 0) {
            $somma += $valore; // aggiorna il totale
        }
    }
    return $somma;
}

Io tendo a scriverla così:

// Somma i valori positivi perché quelli negativi non devono concorrere al totale.
function somma_positivi($valori)
{ $somma=0;                            // totale parziale
  foreach ($valori as $valore)
  { if ($valore>0)                     // considera solo i valori positivi
    { $somma+=$valore;                 // aggiorna il totale
    }
  }
  return $somma;                        // risultato
}

Le regole sono poche: due spazi per ogni livello e niente tabulazioni; parentesi graficamente allineate; commenti sulla stessa riga e possibilmente allineati a destra.

Il commento prima della funzione è l'eccezione: sta a sinistra e dice brevemente che cosa fa quella funzione e perché esiste. Serve anche a me, quando torno sul codice mesi o anni dopo.

Quando è utile, lascio ancora spazio a destra per test, valori attesi o stato dell'algoritmo. Il sorgente può così contenere tre informazioni visivamente separate:

codice  |  significato  |  test / stato atteso

Questo è un metodo personale, non una proposta di stile universale. Nei programmi reali un commento dovrebbe aggiungere soprattutto intenzione, vincoli o valori attesi, non limitarsi a tradurre in italiano l'istruzione accanto. Qui alcuni commenti volutamente elementari servono a rendere visibili le colonne.

Le anomalie diventano visibili

Non è soltanto una questione di leggibilità. La regolarità permette di vedere le anomalie.

// Esempio: un solo spazio fuori posto
  foreach ($valori as $valore)
  { if ($valore>0)
     { $somma+=$valore;                // questo spazio è sospetto
    }
  }

Quel singolo spazio in più non rende necessariamente sbagliato il programma. Ma rompe la geometria e attira immediatamente l'occhio.

Un caso ancora più interessante è questo:

  foreach ($valori as $valore)
  { if ($valore>0)                     // considera solo i valori positivi
    { $somma+=$valore;                 // aggiorna il totale
      $conta++;                         // conta i valori ammessi
    }
      $letti++;                         // conta tutti i valori letti
  }

$letti++ è fuori dal blocco dell'if e potrebbe essere esattamente dove deve stare. Ma sporge senza appartenere graficamente a nulla. Prima ancora di interpretare il codice, quella riga mi invita a controllarla.

Questo è lo scopo.

La sintassi descrive la struttura del programma. L'indentazione la descrive una seconda volta, geometricamente. I commenti e, quando servono, i test aggiungono ulteriori informazioni indipendenti.

Se queste descrizioni non concordano, qualcosa merita attenzione.

Non è un sistema che impedisce di fare errori. È semplicemente un modo di scrivere codice che cerca di fare in modo che gli errori si facciano notare.

← Torna agli scritti