perchè il goto è il male?

[defmaka]

Premessa: non sono un programmatore. Però so mettere le mani in VBA, cosa che mi è servita più volte per migliorare tante procedure ripetitive su cui lavoro.
Leggendo vari tutorial ho visto che il comando goto è odiatissimo. Perchè?
C'è qualche ragione per cui è bene non usarlo?

[blue_tech]

si perchè è facile crear casini e incasinarsi tanto per fare un esempio...

[NoxDaFox]

I motivi sono due:

Il suo utilizzo e' facilmente evitabile, non esistono situazioni in cui il GOTO non sia sostituibile con altre soluzioni.

Rende il codice difficilmente leggibile e interpretabile, qualora si compiano errori diventa decisamente piu' difficile scovarli.

[hendor]

Rende il flusso delle operazioni poco (o per niente) lineare, per cui poi, come ha scritto anche NoxDaFox, il codice rischia di diventare illegibile.

Siccome esistono delle valide alternative, il GOTO lasciamolo nel dimenticatoio

[Haruki]

ti hanno già detto tutto

Aggiungo che il GOTO è per chi non ci capisce una brega di programmazione e non sa come maneggiare correttamente cicli e funzioni per generare comode sub-routine.

[Ronin]

perchè è una scappatoia facile per chi non ha studiato programmazione, ma vuole scriversi da sè le sue routine SENZA pagare un programmatore

[Il Nero]

Sostanzialmente serve a rendere il codice leggibile e manutenibile. In pratica se non programmi a livello professionale, sbattitene e vai di goto.

[blue_tech]

Sostanzialmente serve a rendere il codice leggibile e manutenibile. In pratica se non programmi a livello professionale, sbattitene e vai di goto.

non capisco; hai detto che il goto servirebbe a rendere il codice leggibile e manutenibile?

dai non ci vuole una scienza a capire come fare un for o chiamare una funzione senza l'uso dei goto lasciateli perdere...

[Pongo]

Maddone dice che non sapete un cazzo e vuole le vostre scuse!

[Ronin]

non capisco; hai detto che il goto servirebbe a rendere il codice leggibile e manutenibile?

no, intendeva il contrario, che NON usarlo serve a rendere il codice manutenibile.
ma se il codice in questione è di trenta righe in tutto, chissene del goto

dai non ci vuole una scienza a capire come fare un for o chiamare una funzione senza l'uso dei goto

il goto fondamentalmente è comodo per uscire da un ciclo for sotto condizione senza stare lì a perder tempo per usare un ciclo while: anche il for è inutile, si può fare tutto col while, anche il select case è inutile, si può fare tutto con l'if then; usare for e select case non è solo più veloce (se faccio una selezione solo 1 volta per generare una query dinamicamente che poi impiega 3 minuti, figurati i 5 millisec persi con l'if al posto del select quanto contano), è soprattutto più comodo.

[Il Nero]

Quello che ha detto Ronin. Sia nel senso che intendevo che NON usarlo dovrebbe rendere il codice leggibile e manutenibile, sia riguardo al fatto che in alcuni casi è comodo.

Per esempio una condizione tipica nella quale il goto è comodo ed utile è quella di cicli annidati in cui una condizione sul ciclo più interno deve provocare il break immediato da tutti i cicli. Quello ad esempio secondo la mia modestissima opinione viene leggibilissimo col goto, mentre se lo si fa secondo il mantra "goto = male" bisogna impantanarsi in variabili ed istruzioni condizionali ad hoc che rendono il codice una merda illeggibile, brutta e pure lunga da scrivere.

Invece con una bella label "fuoridalfottutociclo" messa fuori dal ciclo più esterno il codice ne guadagna in leggibilità e non ci si deve fracassare i maroni a scrivere 3000 righe di codice superflue.

[Cherno]

Esistono i vari break e continue per fare quello che dici tu, Nero.

Soprattutto non è vero che goto == male.

[Haruki]

Maddone dice che non sapete un cazzo e vuole le vostre scuse!

digli di farsi un fake e tornare

[NoxDaFox]

Nei linguaggi assembler il GOTO (alias jump) non e' solo utile, e' addirittura necessario.

Il vero problema sta nel fatto che su 10 programmatori, 6 sono autodidatta e 2 sono cerebralmente poco dotati. Indi per cui si crea la leggenda nera del GOTO e si rimedia all'evenienza di ritrovarsi un mare di codice assolutamente illeggibile e facilmente "buggoso" (permettetemi il termine ).

Resta il fatto che il GOTO e' sempre evitabile utilizzando soluzioni altrettanto efficienti; si tratta semplicemente di sapersi ingegnare nel momento della stesura del codice.

[blue_tech]

Esistono i vari break e continue per fare quello che dici tu, Nero.

Soprattutto non è vero che goto == male.

esatto! nel codice ad alto livello hai sistemi per uscire dai cicli come dici senza goto e qui nessuno sta andando a spada trsatta contro il goto... ha delle problematiche oggettive tutto lì...

Nei linguaggi assembler il GOTO (alias jump) non e' solo utile, e' addirittura necessario.

Il vero problema sta nel fatto che su 10 programmatori, 6 sono autodidatta e 2 sono cerebralmente poco dotati. Indi per cui si crea la leggenda nera del GOTO e si rimedia all'evenienza di ritrovarsi un mare di codice assolutamente illeggibile e facilmente "buggoso" (permettetemi il termine ).

Resta il fatto che il GOTO e' sempre evitabile utilizzando soluzioni altrettanto efficienti; si tratta semplicemente di sapersi ingegnare nel momento della stesura del codice.

non è che è necessario, è l'unica cosa che hai se vuoi scrivere qualcosa che salti tra i vari punti del codice... lì non esistono while if for ecc... te li devi costruire con le jump

Il punto è che se uno vuole scrivere codice, tendenzialmente lo fa ad alto livello, e se decide di scrivere ad alto livello che usi i costrutti ad alto livello possibilmente in maniera intelligente...

è ridicolo appoggiarsi al goto che è usato in programmazione a basso livello e che alla lunga preso come abitudine rende il tutto illeggibile

[Haruki]

Nei linguaggi assembler il GOTO (alias jump) non e' solo utile, e' addirittura necessario.

Il vero problema sta nel fatto che su 10 programmatori, 6 sono autodidatta e 2 sono cerebralmente poco dotati. Indi per cui si crea la leggenda nera del GOTO e si rimedia all'evenienza di ritrovarsi un mare di codice assolutamente illeggibile e facilmente "buggoso" (permettetemi il termine ).

Resta il fatto che il GOTO e' sempre evitabile utilizzando soluzioni altrettanto efficienti; si tratta semplicemente di sapersi ingegnare nel momento della stesura del codice.

a) il jump e il goto sono due cose diverse
b) adesso qualcuno ti quoterà dicendo che il goto è inutile se lavori in binario :V
c) questa conversazione sta prendendo una piega ridicola

[Kemper Boyd]

Il GOTO non e' intrinsecamente il male ma ha un grosso difetto: il target del GOTO non e' facilmente intuibile.

Spiego meglio: in qualunque ciclo di controllo hai una keyword di inizio e una di fine (o blocchi definiti da graffe o dall'indentazione come in python o qualunque altra cosa prevista dalla specifica sintassi) quindi hai subito un'idea chiara del flusso che seguono le istruzioni contenute in quella struttura, e' immediatamente comprensibile dove inizia e dove finisce.

Con GOTO e LABEL invece questo non e' vero, puoi avere limitazioni dovute allo scope (difficilmente potrai usare un GOTO per uscire da una funzione ad esempio), ma comunque in un grosso pezzo di codice la LABEL potrebbe trovarsi teoricamente ovunque rendendo l'analisi del codice un continuo salto qua e la' con stringhe di ricerca. Ovviamente un "unico grosso pezzo di codice" e' raramente una buona cosa quindi gia' quello non e' indice di buona programmazione, ma il GOTO non fa che complicare le cose. In un linguaggio di alto livello ci sono davvero pochissimi casi in cui abbia senso usarlo, mentre e' molto facile usarlo a sproposito creando casino.

[Recidivo Visual]

La risposta alla domanda dell'argomento si trova benissimo su wiki e diciamo che si fonda sopratutto nell'idea di avere una programmazione strutturata:

Le idee chiave della programmazione strutturata si possono ricondurre alla critica della struttura di controllo del salto incondizionato (o goto, "vai a"), che rappresentava, negli anni sessanta, lo strumento fondamentale per la definizione di algoritmi complessi nel software. In un celebre articolo del 1968, Goto statement considered harmful, Edsger Dijkstra discusse approfonditamente gli effetti deleteri del goto sulla qualità del software, e in particolare sulla sua leggibilità e modificabilità (il cosiddetto problema dello spaghetti code).
Un'altra celebre pubblicazione che risultò fondamentale all'affermarsi della programmazione strutturata fu Flow Diagrams, Turing Machines, and Languages with Only Two Formation Rules, in cui Corrado Böhm e Giuseppe Jacopini dimostrarono il loro celebre teorema. Secondo tale teorema, qualsiasi programma scritto usando il goto poteva essere riscritto senza, a patto di avere a disposizione altri tre tipi di strutture di controllo: sequenza, ripetizione e alternativa. Il risultato di Böhm-Jacopini può anche essere espresso dicendo che, dato un qualunque diagramma di flusso, ne esiste almeno un altro che a parità di input produce sempre gli stessi output del primo e in cui i nodi del diagramma di flusso rispettano un certo insieme di vincoli.

C'e' da dire che il problema non e' nel goto stesso, ma nell'uso che se ne fa.
Il problema non sono gli strumenti ma come vengono utilizzati dal carpentiere informatico ( programmatore) cosi':

Ai giorni nostri l'uso di questa istruzione in linguaggi ad alto livello è generalmente considerato indice di cattiva programmazione (il cosiddetto "spaghetti code"). Tuttavia, in linguaggi che non prevedano le eccezioni, GOTO può essere una valida scelta nel caso di rollback di operazioni o deallocazione di risorse allocate attraverso passi successivi, quando in uno di tali passi si verifichi una condizione di errore. Il codice sorgente del kernel Linux è ricco di GOTO, spesso finalizzate a tale scopo.

Marco.

EDIT:

C'e' anche un esempio:

Il seguente programma è un esempio banale di spaghetti code in BASIC. Esso stampa su schermo la sequenza di numeri da 1 a 10 e il loro quadrato. Si noti come le istruzioni di goto introducano una dipendenza dai numeri di riga del programma, e come il flusso di esecuzione salti in maniera impredicibile da una zona all'altra. In pratica, nei programmi reali le occorrenze di spaghetti code sono ben più complesse e possono aumentare notevolmente i costi di manutenzione di un programma.

10 dim i  
20 i = 0  
30 i = i + 1  
40 if i <= 10 then goto 70 
50 print "Programma terminato."  
60 end  
70 print i & " al quadrato = " & i * i  
80 goto 30 

Ecco un esempio di codice equivalente scritto con uno stile di programmazione strutturato:

 
function square(i)     
  square = i * i 
end function   
 
dim i  
for i = 1 to 10     
  print i & " al quadrato = " & square(i) 
next 
print "Programma terminato." 

Anche questo programma esegue salti, ma in questo caso si tratta di salti predicibili e formalizzati. Questo perché il ciclo for e le funzioni definiscono flussi di controllo standardizzati, mentre le istruzioni goto incoraggiano flussi di controllo arbitrari.

[NoxDaFox]

a) il jump e il goto sono due cose diverse

http://gcc.gnu.org/onlinedocs/gcc-3....as-Values.html
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

b) adesso qualcuno ti quoterà dicendo che il goto è inutile se lavori in binario :V

questa non l'ho capita.

c) questa conversazione sta prendendo una piega ridicola

nemmeno questa l'ho capita.

[Cherno]

esatto! nel codice ad alto livello hai sistemi per uscire dai cicli come dici senza goto e qui nessuno sta andando a spada trsatta contro il goto... ha delle problematiche oggettive tutto lì...


non è che è necessario, è l'unica cosa che hai se vuoi scrivere qualcosa che salti tra i vari punti del codice... lì non esistono while if for ecc... te li devi costruire con le jump

Il punto è che se uno vuole scrivere codice, tendenzialmente lo fa ad alto livello, e se decide di scrivere ad alto livello che usi i costrutti ad alto livello possibilmente in maniera intelligente...

è ridicolo appoggiarsi al goto che è usato in programmazione a basso livello e che alla lunga preso come abitudine rende il tutto illeggibile

E' anche vero che delle volte ti ritrovi a lavorare con del codice critico scritto col culo, nel quale non puoi permetterti di fare modifiche a certe logiche. In quel caso c'è poco da filosofeggiare e magari un bel goto non te lo toglie nessuno.

Le situazioni sono tante: dire che il goto è il male è una puttanata, dire che spesso è usato in maniera impropria, già rispecchia di più la realtà

[blue_tech]

beh ma è quello che stiamo dicendo dall'inizio...
il goto è uno strumento, purtroppo sono in tanti ad usarlo alla pene di cane quindi tendenzialmente viene considerato il male... poi ovvio che chi lavora seriamente e lo usa quando e dove necessario e nella misura necessaria, fa bene

[Haruki]

http://gcc.gnu.org/onlinedocs/gcc-3....as-Values.html
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

Mi pare proprio che ambedue confermino la mia tesi, quindi?

[hendor]

C'è gente che riesce ad usare a pene di cane pure i for, while, e if, figuriamoci i goto

[blue_tech]

C'è gente che riesce ad usare a pene di cane pure i for, while, e if, figuriamoci i goto

[Cherno]

beh ma è quello che stiamo dicendo dall'inizio...
il goto è uno strumento, purtroppo sono in tanti ad usarlo alla pene di cane quindi tendenzialmente viene considerato il male... poi ovvio che chi lavora seriamente e lo usa quando e dove necessario e nella misura necessaria, fa bene

ronin sostiene che chi fa uso del goto è perchè si improvvisa programmatore e vuole programmarsi le cose da se senza pagarne uno, per esempio.