Il Goto E La Buona Programmazione [Parte III]

Se avete seguito i due articoli precedenti a questo (potete ancora mettervi in pari leggendoli qui e qui ) sapete che, fresco di università, avevo provato ad adattare un driver del kernel di linux e mi ero trovato davanti alla temibile goto, riscrivendo la formula però mi sono accorto che essa risultava più lunga e più complessa di prima, come fare a risolvere questo problema?

Possiamo programmare senza ricorrere a Goto? Che alternative abbiamo?

Esistono altre soluzioni possibili senza l’uso di goto, ne riporto solo una per motivi di praticità:

if (!get_resource1())
    return error1;

if (!get_resource2())
    {
        release (resource1)
        return error2;
    }

if (!get_resource3())
    {
        release (resource2);
        release (resource1);
        return error3;
    }

if (!get_resource4())
    {
        release (resource3);
        release (resource2);
        release (resource1);
        return error4;
    }

...corpo della funzione...

  release (resource4);
  release (resource3);
  release (resource2);
  release (resource1);

return 0;

Questa soluzione è certamente migliore dell’anti-pattern arrow, ma rispetto a quella che utilizza i goto presenta punti di uscita multipli, forte duplicazione del codice e problemi di manutenibilità (bisogna prestare particolare attenzione per aggiungere un nuovo caso).

Come dicevo, ci sono altre possibilità, i lettori che hanno familiarità con i linguaggi di alto livello sicuramente diranno che il problema potrebbe facilmente risolversi con l’utilizzo delle eccezioni. Bisogna però notare che la gestione delle eccezioni non è supportata da tutti i linguaggi, inoltre, non me ne vogliano i puristi, le eccezioni non sono altro che dei goto sotto mentite spoglie.

Chiarisco meglio il concetto per evitare flame nei commenti. L’eccezione cosa fa di preciso ? Sospende l’esecuzione sequenziale del programma per eseguire il codice di gestione della condizione inaspettata, in pratica quello che fa il goto nel nostro esempio, ovvero quando è usato bene (in realtà le eccezioni fanno qualcosa di più ma il concetto alla base è questo).

Concludo dicendo che il mio proposito non è quello di riabilitare il go to, che ha già perso la sua guerra negli anni 60, un uso sconsiderato porta a codice ingarbugliato difficile da decifrare (spaghetti code) anche per l’autore stesso, tuttavia esistono casi in cui il suo uso è ancora  legittimo. Ancora più importante, è sottolineare che nella programmazione, (come in qualsiasi attività umana) applicare le regole alla cieca spesso non è sufficiente per ottenre un risultato soddisfacente, non bisogna accettare ogni regola come un dogma, ma capire quali sono le motivazioni che hanno portato alla sua introduzione, e quali sono i suoi limiti di applicabilità.

© 2008 Ziogeek.com

Tag: goto, Programmazione