Newsgroup: it.comp.lang.visual-basic
Titolo: variabili locali vs. globali

sono appena passato da un progetto ad un altro.
in uno l'analista odiava le variabili globali e aveva dato precise
istruzioni per ridurle al minimo.
nell'altro il responsabile (che non era specificamente l'analista ma
quasi) invece le apprezzava particolarmente.  in particolare sono
stati dimensionati come globali contatori per scorrere insiemi,
recordset, variabili edi appoggio, ecc.
nel primo caso la giustificazione era fondamentalmente di carattere
organizzativo, si evitano interferenze.  anche io dopo le prime
infatuazioni con le var a visibilita' globale mi sono trovato meglio
con quelle locali.
nella seconda secondo il tizio si risparmiava spazio in memoria
dichiarando un solo contatore globale ed usando sempre quello,
piuttosto che dichiararne uno a visibilita' locale ogni volta che ce
n'era bisogno, perche' tanto non veniva scaricato alla fine della
routine.
io propendo per il primo orientamento, variabili globali il meno
possibile, che si fa meno casino.  inoltre questa storia delle
variabili locali che continuano ad occupare spazio una volta che la
routine e' conclusa mi torna nuova.
consigli, idee, suggerimenti?
======================================================
my opinions do not necessarily have to be true.
======================================================
per rispondermi rimuovere NOSPAM. dall'indirizzo email
to answer me remove NOSPAM. from email address
======================================================

consigli, idee, suggerimenti?
Salvo occasioni ben ponderate, sempre variabili locali.
Domenico

Mha !
Io invece mi trovo meglio utilizzando un certo numero di variabili globali
predefinite, ad esempio
due recordset generici, due tabledefs generici ecc. ecc.
Sicuramente le locali vengono scaricate dalla memoria alla chiusura della
routine, ma e` altrettanto
sicuro che + routine contemporanee che lavorano sugli stessi dati con
variabili locali (passate come
property) finiscono , in quel particolare momento, per utilizzare piu`
memoria.
Non va dimenticato infine che definendo un certo numero di variabili globali
predefinite i moduli
risultano meno appesantiti dalle dichiarazioni e percio` probabilmente un
po` piu` leggibili
(e poi ridichiarare sempre le stesse variabili e` un po` una rottura !).
Ciao.

consigli, idee, suggerimenti?

Io direi semplicemente di usare le variabili Globali solo quando devono
essere visibile su più form (e a volte non serve nemmeno)
Locali a livello di form quando devono essere visibili a più routines nel
form e locali quando servono solo alla routine.
Ho detto una banalità, no? e allora, visto che è banale, perché non
seguirla?

Io le variabili globali non le userei in nessun caso.
Se devi accedere da piu' form alle stesse variabili puoi usare le property.
In questo modo dai un taglio "per componenti" alla tua applicazione e
definisci fra questi un'interfaccia piu' forte.
Ciao
Stefano

consigli, idee, suggerimenti?
Se avete questi problemi di prestazioni, suggerirei l'assembler  :->
Scherzi a parte, ha senz'altro ragione il primo analista.
Le variabili globali hanno senso solo se la loro durata deve essere la
stessa dell'applicazione.
A livello di modulo di classe (per esempio quelli delle form) definisci le
variabili che devono essere legate all'istanza della classe.
Ha senso usare variabili non locali anche se giudichi che dovresti mettere
troppi argomenti nelle chiamate alle procedure per passare valori da una
procedura all'altra.
Io però in questo caso mi limito a variabili definite a livello di modulo
(non globali ma comuni a tutte le procedure del modulo), e cerco di limitare
in questi moduli il numero di procedure.
Ovviamente, uso sempre option explicit all'inizio di ogni modulo.
L'unico criterio che guarderei è quello della leggibilità del codice, credo
che sia il caso di ottimizzare le prestazioni solo quando c'è uno scadimento
avvertibile.
Ne avevo già parlato in questo newsgroup, ma mi sembra in tema aggiungere
che mi trovo molto bene usando le convenzioni di Reddick e Leszinski (o qc
del genere, vedi articolo sulla knowledge base della Microsoft), che
suggeriscono (tra l'altro) un prefisso "m" per le variabili dichiarate a
livello di modulo
e "p" per le variabili globali.
Infine, scrivendo codice hai il completamento automatico (lo odi? io lo
trovo stupendo!) e la modifica delle maiuscole/minuscole solo per le
variabili che sono state dichiarate visibili per il codice che stai
modificando.
Così se hai scritto "for pippo...", quando premi invio ti diventa "For
Pippo..." solo se la variabile Pippo è stata validamente dimensionata per la
procedura.
Avere dimensionate delle variabili sicuramente inutili per una procedura
serve solo ad aumentare la confusione e la possibilità di errori.
Saluti
The_Force

...

probabilmente il motivo fondamentale che ti spinge ad utilizzare le
variabili globali e' soltanto quello scritto tra parentesi, ma secondo me la
pigrizia si paga cara.
Infatti le variabili globali rendono difficile la modifica del codice (se il
codice e' stato scritto da chi lo modifica), per non dire addirittura
"impossibile" (se chi lo modifica non e' la persona che lo ha scritto). La
presenza delle variabili globali lascia sempre il dubbio che le modifiche
apportate possono creare danni.
Dopo aver effettuato una modifica e' necessario in ogni caso riguardare
tutto il codice, esaminado ogni singola istanza dell'uso della variabile
(bella rottura).
Per quanto riguarda la memoria, il fatto che le variabili locali vengono
caricate e scaricate della routine in cui sono definite garantisce
l'utilizzo ottimale della memoria; al contrario del caso in cui definisco
una variabile globale che poi non verra' mai utilizzata perche' le routine
che ne fanno uso non vengono richiamate.
Ciao
Paolo

(e poi ridichiarare sempre le stesse variabili e` un po` una rottura !).
Sono d'accordo con l'ultima affermazione.
Però sono convinto che una procedura o un modulo che non dimensiona
localmente le variabili che non devono essere condivise con altre procedure
non è più leggibile.
Leggendo un codice che usa una variabile posso chiedermi in quale altro
posto viene usata la stessa variabile. Se la trovo nelle dichiarazioni a
livello di procedura ho subito la risposta: la variabile non è usata in
nessun altro posto, e per capire perché diavolo ha quel valore strambo che
non deve avere mi basta sicuramente guardare la procedura.
Altrimenti devo cercare anche altrove; finché hai una decina di procedure
può essere fattibile, ma quando le dimensioni dei moduli o dei progetti
aumentano rischia di essere laborioso...
The_Force

due recordset generici, due tabledefs generici ecc. ecc.
E' gia' il problema e' che ogni qual volta che ti porti in giro una
procedura su un'altro programma ti tocca generarle.
In ogni caso se sono solo due tre non e' un grande problema ma se usi
un pezzo di codice in un programmino che usa tabelle ti tocca crearle
per niente.
--------------------------------------------------------
Paolo Hölzl
Metis Informatica S.r.L technical manager (Ferrara)
--------------------------------------------------------
ATTENZIONE!, antispam 
per reply sostituire xxxx.xxxxxxx.xx con 
mail.asianet.it

Sempre e solo variabili locali. Questo è il mio credo.
Esistono poi tecniche OOP per creare meccanismi di visibilita' globale. Ma
solo per alcune situazioni (Database, Errori, Sicurezza)
-----------------------------------------------------------------------
-----------------------------------------------------------------------
 Dini Daniele                   MailTo:
d.d...@pippoesa-group.it
  Progettista Software  Togliere pippo per rispondere
  Analista Programmatore
 ESA Software S.p.A.            
http://www.esa-group.it
 via Draghi, 39                 tel.: +39 541 368.111
 47900 Rimini (ITALY)           fax : +39 541 368.268
-----------------------------------------------------------------------
-----------------------------------------------------------------------

...

Per quanto mi riguarda cerco di usare sempre delle variabili locali, ma in
alcuni casi uso delle variabili globali (con parsimonia).
Nella mia procedura gestionale che fa uso di almeno una trentina di database
trovo comodissimo dimensionare come globali un database, un paio di
recordset, un paio di flag, una variant e una stringa nella quale schiaffo
dentro le formule sql (infatti la chiamo sqlstr)
Certamente è sconveniente definire come globali tutte le variabili,
contatori ecc. sia come leggibilità che come semplicità nel fare le
successive modifiche...
--
"Baby, vieni qui che ti devo parlare da vicino..."
----------------------------------------------------------
Night Eagle ti aspetta su:              U_/
http://space.tin.it/io/mzugar/
       / R
----------------------------------------------------------
Togliere 'FUCKSPAM' per le risposte


Premetto che le tecniche OOP andrebbero sempre seguite e messe in pratica.
In ogni caso, anche con linguaggi non ad oggetti (come il C) e' decisamente
piu' conveniente seguire le stesse norme generali della OOP, che portano a
numerosi vantaggi:
- maggiore leggibilita' del codice
- maggiore manutenibilita' di progetti di qualsiasi dimensione
- possibilita' di sviluppo in parallelo di piu' programmatori senza
particolari difficolta' (almeno se lavorano su "oggetti" differenti)
- immediata visibilita' della struttura globale del progetto (ma la
documentazione e' sempre necessaria!)
Per cui:
NO! alle variabili globali inutili.
Le variabili globali sono veramente utili solo in pochissimi casi; a volte
risultano comode per situazioni particolari, per evidenziare uno stato
globale dell'applicazione o una sua configurazione.
Es. la variabile globale "gInRete As Boolean" e' messa a True alla partenza
dell'applicazione se si sta usando un database in rete, invece di quello
locale. Tale variabile identifica uno stato generale.
Quasi sempre l'uso di variabili globali porta a problemi imprevedibili e bug
difficilmente scovabili.
Es. una variabile contatore di ciclo dichiarata globalmente utilizzata
contemporaneamente...
Public i As Integer
Sub A()
    for i=0 to 10 do
        < qualcosa>
End Sub
Sub B()
    for i=0 to 100 do
        A()
End Sub
Morale della favola...
Evidentemente il secondo responsabile (che non e' un analista, ma non sa
evidentemente un ca**o nemmeno di programmazione) ha detto un mare di
stupidate... forse lui era abituato ai programmi su vetusti mainframe dove
il risparmio anche di un solo byte era l'obiettivo principale...
sfido chiunque a leggere uno di quei programmi e a non diventare pazzo
tentando di seguirne il flusso e capirne il funzionamento!
Roal Zanazzi
z...@iol.it

appoggio pienamente!!!
Riccardo