Visual basic script: scope, convenzioni e stringhe

Dopo aver introdotto le procedure e le funzioni, ed esserci quindi posti nelle condizioni di rendere i nostri programmi un po’ strutturati e complessi, è arrivato il momento di vedere come “scrivere bene” il codice per non perderci nella complessità. Ci occuperemo delle convenzioni sulla scrittura delle varie componenti del programma, in particolare sui nomi da assegnare alle variabili ed alle funzioni; daremo qualche consiglio di struttura per rendere più leggibile il codice e chiuderemo spiegando lo scope .

Convenzioni di assegnazione nomi (naming convention)

Genericamente ogni linguaggio di programmazione o gruppo di sviluppo ha delle convenzioni proprie; d’altra parte, lo scopo delle convenzioni di scrittura è quello di rendere leggibile il codice sia ad eventuali altri lettori, sia al programmatore stesso: spesso e volentieri capita che un programmatore alle prime armi scriva del codice e dopo qualche tempo non ricordi cosa esso faccia o il significato di alcuni passaggi… e decisamente è una cosa che si vuole evitare!
 
In questo paragrafo andremo a descrivere le convenzioni più comuni che ritroverete sicuramente in giro per il web se andate a cercare codice di altri programmatori.
 
Possiamo identificare le seguenti convenzioni principali:

Convenzioni di scrittura delle variabili: il metodo più utilizzato è una derivazione diretta dello stile chiamato “Camel Case” che consiste nello scrivere una parola composta con le iniziali delle componenti maiuscole, eccetto la prima… un esempio chiarirà: unNomeMoltoLungo è un nome scritto in formato CamelCase.
La scrittura delle variabili deriva da questo metodo, in quanto si ha l’”obbligo” di scrivere nella prima parola il tipo di dati della variabile e poi il suo nome.
Il nome della variabile deve essere quanto più descrittivo possibile, anche se bisogna stare attenti a non esagerare nell’eccessiva lunghezza: temp1, variab o test1 sono nomi non accettabili, alla stessa maniera di variabileappoggiodovemetteiltot (i testi “puristi” dicono che oltre i 32 caratteri risulta leggibile, ma anche i 31 dell’esempio fatto non ci paiono molto più chiari).

• Boolean: prefisso bln (o b), ad esempio blnEsatto o bEsatto;
• Byte: prefisso byt, ad esempio bytDato;
• Integer: prefisso int (o i), ad esempio intTotale o iTotale;
• Datetime: prefisso dtm, ad esempio, dtDataNascita;
• Double: prefisso dbl (o d), ad esempio dblTolleranza o dTolleranza;
• Long: prefisso lng (o l), ad esempio lngDistanza o lDistanza;
• Object: prefisso obj (o o), ad esempio objFileInput o oFileInput;
• String: prefisso str (o s), ad esempio strNome o sNome;

Convenzioni di scrittura delle costanti: per le costanti ci sono due scuole di pensiero, entrambe usate e valide; la prima consiste nello scrivere il nome della costante tutto maiuscolo, separando eventuali nomi composti con degli underscore (i.e. NUMERO_MAX_UTENTI); la seconda ricalca la convenzione di prima: si utilizza il camel case, anteponendo alla variabile il prefisso “con” (i.e. conNumMaxUtenti);
 
Convenzioni di scrittura dei nomi di routine: anche i nomi che assegniamo alle routine devono essere quanto di più descrittivi possibile: nomi di funzione “Function Funzione1()” non dicono niente su ciò che fa la funzione. In genere i nomi cominciano con un verbo che indica l’azione che ci si aspetta che faccia seguita da un nome comprensibile (setMaxVal, getMedia, closeAllFiles);

Convenzioni per i commenti

Anche per i commenti, non ci sono regole universali da seguire se non quella universale: il giusto mezzo.
 
Generalmente all’inizio del programma si inserisce l’autore del programma, la data in cui è stato scritto, la data dell’ultima modifica ed una descrizione del suo funzionamento.
 
Nel corpo, invece, vanno commentati con i passaggi fondamentali o di non immediata comprensione: non ha senso commentare tutte le istruzioni, o si rischia di appesantire inutilmente il codice.
 
Un discorso particolare va fatto per i commenti associati alle routine; innanzitutto è necessario inserire una breve descrizione del funzionamento generale della routine stessa senza però scendere nei dettagli delle modalità di implementazione: dato che generalmente tali modalità vengono cambiate con una certa frequenza, si rischia di impiegare più tempo a fare manutenzione che a scrivere codice.
Buona norma è inserire un commento in merito ai parametri passati in ingresso, specificando il significato di quelli meno evidenti e/o il range di dati ammesso.
Infine, nel caso delle funzioni, bisogna descrivere i parametri di uscita sia come significato che come tipo di dato.

Formattazione del codice

Per quanto possa sembrare strano o solo un vezzo, anche la formattazione del codice è fondamentale: deve poter suggerire al lettore i livelli di nidificazione del programma in maniera immediata, e suggerire lo schema mentale che c’è dietro all’algoritmo, favorendo così sia la leggibilità sia la comprensibilità del programma.
 
D’altra parte, è innegabile che un codice così fatto:

' Ciclo fino a che l'utente restituisce un valore numerico
Do
' Prendo il raggio come stringa da inputbox
sRaggio = InputBox("Inserire il raggio del cerchio.")
 
if IsNumeric(sRaggio) Then
 
' Converto il raggio in un double
dRaggio = CDbl(sRaggio)
 
' Richiamo la funzione che calcola l'area
dArea = AreaCerchio(dRaggio)
 
' Restituisco a video il risultato
msgbox "L'area del cerchio corrispondente e' " + CStr(dArea)
Else
' Messaggio di errore: non e' un numeor
msgbox "Il valore inputato non e' un numero, pertanto il programma terminerà"
End if
 
Loop while IsNumeric(sRaggio)
 
è assai meno leggibile del suo corrispettivo indentato:
 
' Ciclo fino a che l'utente restituisce un valore numerico
Do
' Prendo il raggio come stringa da inputbox
sRaggio = InputBox("Inserire il raggio del cerchio.")

if IsNumeric(sRaggio) Then

' Converto il raggio in un double
dRaggio = CDbl(sRaggio)

' Richiamo la funzione che calcola l'area
dArea = AreaCerchio(dRaggio)

' Restituisco a video il risultato
msgbox "L'area del cerchio corrispondente e' " + CStr(dArea)
Else
' Messaggio di errore: non e' un numeor
msgbox "Il valore inputato non e' un numero, pertanto il programma terminerà"
End if
 
Loop while IsNumeric(sRaggio)

Anche nel caso della formattazione e delle indentazioni non esiste una regola univoca: negli esempi che abbiamo riportato abbiamo indentato con una tabulazione l’insieme delle istruzioni appartenenti allo stesso “blocco”; altri testi suggeriscono di usare le indentazioni anche per le istruzioni che seguono i commenti iniziali, e di mettere i commenti delle singole istruzioni sulla stessa riga dell’istruzione stessa…
 
Anche qui, non esistono regole “scritte nella pietra”: la cosa importante è che anche a distanza di tempo, il codice risulti immediato da leggere e facilmente mantenibile.

Variabili e funzioni: scope

Chiudiamo questa lezione spiegando quello che in gergo si chiama “scope” delle variabili, ovverosia la visibilità di una variabile.
 
Creiamo un nuovo programma, e chiamiamolo TestScope.vbs

 
'-------------------------------
' Name: TestScope.vbs
' Author: Jeff Skyrunner
' Date: 25/06/10
' Desc: Esempi di scope
'------------------------------
 
 
Dim iNumerica
 
iNumerica = 5
 
msgbox iNumerica
 
NonCambiaValore()
 
msgbox iNumerica
 
CambiaValore()
 
msgbox iNumerica
 
 
Sub NonCambiaValore()
Dim iNumerica
iNumerica = 7
End Sub
 
 
Sub CambiaValore()
iNumerica = 8
End Sub

Abbiamo volutamente lasciato il codice non commentato, per poter vedere nel dettaglio il comportamento delle variabili, e capire anche meglio quanto abbiamo detto nel paragrafo precedente, in merito al dare un nome comprensibile alle variabili.
 
Dando una prima occhiata al codice potrebbe sembrare che venga utilizzata solamente una variabile, ovvero iNumerica; in realtà le variabili usate sono due, entrambe di nome iNumerica. Questo contraddice solo apparentemente la regola di assegnare un nome univoco alle variabili, proprio perché esiste una variabile ha una sua vita solo all'interno del macro elemento in cui è definita:

Sub NonCambiaValore()
Dim iNumerica
iNumerica = 7
End Sub
 
 
Sub CambiaValore()
iNumerica = 8
End Sub

la differenza sostanziale tra queste due procedure è che in NonCambiaValore noi definiamo una nuova variabile iNumerica, che “vive” solo fino all' End Sub; per questo motivo, quando poi nel corpo principale del programma andiamo a dare il msgbox con il contenuto di iNumerica il risultato non è cambiato: il valore 7 è stato assegnato alla variabile iNumerica che “viveva” solo all'interno della funzione NonCambiaValore mentre il msgbox è nel corpo principale e “non sa dell'esistenza” di iNumerica. Con la terminologia tecnica opportuna, si dice che iNumerica era una variabile locale della funzione NonCambiaValore.

Nella funzione CambiaValore, invece, iNumerica non è ridefinita, quindi quando assegniamo il valore 8 lo stiamo facendo sulla variabile globale iNumerica, ovvero quella definita nel corpo principale; il msgbox ci dimostra che quanto detto è vero, in quanto viene visualizzato proprio il valore 8.
 
Con una breve digressione un po' più tecnica, si può dire che con la variabile iNumerica di NonCambiaValore abbiamo applicato la tecnica dello shadowing, ovvero del mascherare il valore di una variabile con una omonima; questa tecnica è molto pericolosa se non usata intenzionalmente per fini particolari, in quanto si rischia di perdere di vista il valore corretto della variabile.

A cura di Jeff Skyrunner