Corso visual basic script\Gestione della sequenza delle istruzioni

Guido Ruggeri su winguidotecnica, 23\12\2009, h. 01.25.

Per i prossimi esercizi, dovremo cominciare a porci un nuovo
tipo di problema: quello di gestire la sequenza delle
istruzioni.
Finora abbiamo scritto programmi con al massimo 3 righe, e,
anche senza mai parlarne, abbiamo dato per scontato
qualcosa: che l'interprete avrebbe eseguito dapprima la
prima riga, poi la seconda, e infine la terza.
Consideriamo ad esempio l'esercizio 4.
Le 3 righe erano:

Ed ora, un po' di pubblicità

Cognome = "Ruggeri"
Nome = "Guido"
Msgbox "Io mi chiamo: " & Nome & " " & Cognome

Cosa sarebbe successo se l'interprete fosse partito dalla
terza riga, senza prima eseguire le altre due?
Che avrebbe trovato le variabili Cognome e Nome vuote,
perciò sarebbe apparso un messaggio con la sola scritta:
"Io mi chiamo: "
(notare i due spazi vuoti finali).
Dato che invece, quando abbiamo provato l'esercizio, questo
non è successo, dobbiamo ritenere che l'interprete abbia
eseguito dapprima la prima riga, assegnando il valore
"Ruggeri" alla variabile Cognome, poi la seconda riga,
assegnando "Guido" alla variabile Nome, e infine la terza
riga, facendo apparire il messaggio.
Bene, fin qui niente di strano: se scriviamo un programma di
sole 3 righe, è naturale considerare che l'interprete
debba eseguirle tutte e tre, dalla prima fino alla terza.
Ma immaginiamo un programma più grande, dove le righe
comincino ad essere decine, centinaia, migliaia.
Quante righe di programma ci sono nel sorgente di WinGuido?
Certo non le ho mai contate, ma grosso modo potrebbero
essere intorno alle cinquantamila.
Naturalmente non può essere che, ogni volta che avviate
WinGuido, vengono eseguite tutte quelle righe, dalla prima
fino alla cinquantamillesima. Ci dovranno invece essere dei
meccanismi che consentano di selezionare, a seconda delle
varie scelte fatte via via dall'utente, quali parti del
programma andare ad eseguire, potendo saltare da una parte
all'altra secondo il caso.
Torniamo al nostro esercizio 4.
L'avete provato, e avete ottenuto l'effetto che: il
programma chiede il cognome, poi chiede il nome, infine fa
apparire il nominativo. Poi il programma finisce.
Supponiamo di volere che il programma, invece di finire,
ricominci da capo ripartendo dalla prima riga. Cioè, dopo
aver ricevuto un cognome, un nome, e aver mostrato un
nominativo, si ridisponga a chiedere un nuovo cognome, e poi
un nuovo nome.
Supponiamo ad esempio di incontrarci tutti quanti, con un
solo computer, e di voler fare un unico programma dove
ognuno di noi, a turno, possa scrivere il suo nome.
In qualche modo dovremo quindi dire all'interprete: guarda,
dopo che hai eseguito la terza riga, voglio che torni alla
prima e riprendi da lì.
Come si fa?
Per adesso ancora non ve lo dico, ma vi parlerò di come si
faceva una volta.
Nelle prime versioni di Basic, l'ambiente di sviluppo
assegnava automaticamente ad ogni riga un numero, visibile
all'utente.
Il nostro programma ci sarebbe quindi apparso così:

1 Cognome = "Ruggeri"
2 Nome = "Guido"
3 Msgbox "Io mi chiamo: " & Nome & " " & Cognome

In realtà, chi ci ha lavorato veramente ricorda che la
numerazione andava di dieci in dieci, quindi le righe
sarebbero state: 10, 20 e 30. Ma lasciamo perdere questo
aspetto, e atteniamoci a 1, 2 e 3.
L'esecuzione naturale del programma, abbiamo detto, inizia
dalla prima riga e poi prosegue alla riga successiva, e
così via di riga in riga, fino all'ultima.
C'era però un'istruzione specifica che serviva a cambiare
la successione delle righe nell'esecuzione, ed era
l'istruzione: GoTo, che significa: "vai a".
Nel programma avrei quindi dovuto aggiungere una quarta riga,
così fatta:

4 GoTo 1

che significa: vai alla riga 1.
Quindi il programma, dopo aver eseguito la riga 3 e cioè
dopo aver fatto apparire la finestra con nome e cognome,
avrebbe ricominciato dalla prima riga, chiedendo un nuovo
cognome, poi un nuovo nome, e così via.
L'istruzione Goto, unita alla numerazione delle righe, era
quindi facile e immediata da usare.
Ma, proprio per questo, aveva un difetto: disabituava il
programmatore a strutturare il suo programma in modo
ordinato.
Il continuo ricorso all'istruzione GoTo finiva per rendere
il programma caotico e ingarbugliato, e quindi difficile da
mantenere, specialmente nel caso in cui al codice sorgente
avessero dovuto lavorare più persone distinte.
Per fare un paragone, avete presente quando andate in uno di
quegli edifici pubblici per svolgere pratiche burocratiche?
Supponiate che vi dicano: innanzitutto devi andare al terzo
piano a prendere il numero per la fila, poi vai al
pianterreno a fare la fila. Dopo la fila, ti daranno dei
documenti, vai al quinto piano a farteli timbrare. Poi vai
al piano seminterrato a prendere i bollettini per il
pagamento. Poi vai al secondo piano e prendi un altro
numero, poi vai al quarto piano a fare la fila per la cassa,
poi... bastaaa!!!! non ci si capisce più niente! ma chi
è che ha organizzato le cose, qui?!!
Insomma, l'istruzione GoTo è caduta in disuso, per essere
sostituita da costrutti più strutturati.
In Visual Basic 5 o 6 l'istruzione GoTo esiste ancora, per
una esigenza di compatibilità con le versioni precedenti,
ma qualsiasi guida sconsiglia di usarla.
In VBScript tagliamo la testa al toro: l'istruzione GoTo non
c'è, e perciò non la useremo.
Ci saranno quindi altri tipi di costrutto che la
sostituiscono.
E nelle prossime lezioni dovremo cominciare a conoscere
quali sono.
Guido Ruggeri.