Newsgroup: it.comp.programmare
Titolo: Il diavolo e le variabili globali

So già perché usare le variabili globali è male. E infatti non le uso, 
se posso. Però certe volte devo, come per esempio nelle preferenze di un 
programma: quelle cosa sono se non variabili globali?
Più in generale, voi come vi regolate quando avete dei dati che devono 
essere visibili da più parti del codice e quindi dovete per forza 
renderli globali?


Le mie variabili globali sono precedute tutte da
GL_<eccetera> e resisto alla tentazione di usare
nomi brevi come faccio di solito, quindi dopo
l'underscore cerco di usare un nome più descrittivo
possibile.
So che è una zozzeria ma certe volte delle V.G. non
si può fare a meno :(
-- 
l'apoteosi...
http://www.youtube.com/watch?v=NwGiEl3UYCA&playnext_from=TL&videos=AVYLg4Rgt_M


Io le globali tendo a metterle sempre in una struttura di comodo
struct global
{
  FILE *in_file;
  FILE *out_file;
  char *buffer_da_allocare;
  ...
}
poi istanzio una variabile globale della struttura et voila'
struct global global;
global.in_file = fopen(...);
buffer_da_allocare = malloc(...);
cosi' alla fine, prima di uscire (specialmente per errore), chiudo e
disalloco tutti quello che c'e' da chiudere o disallocare.

 buffer_da_allocare = malloc(...);
che naturalmente era
 global.buffer_da_allocare = malloc(...);


bella e me ne approprio. Ovvero, di metterle in una
struttura lo faccio spesso ma non ho mai pensato
all'allocazione dinamica.


 poi istanzio una variabile globale della struttura et voila'
Sě, infatti č un'idea... il post mi era venuto riflettendo 
sull'antipattern "carica e spara" in cui si fanno una serie di modifiche 
alle variabili globali PRIMA di chiamare una funzione che dipende da 
parecchie di loro, con il rischio di scordarsene qualcuna.
E questo č _MALE_.
Ma alla fin fine se si usano variabili globali č perché qualcosa dipende 
da loro, no? Quindi quando č necessario cambiare queste variabili 
bisogna farlo PRIMA di chiamare le funzioni che le usano.
In altre e piů chiare parole: quando č che io uso correttamente le 
variabili globali e quando č invece che mi sto infilando in un 
antipattern "carica e spara"? Non mi č chiaro, ehm...
link alla pagina:
http://it.wikipedia.org/wiki/Carica_e_spara

 antipattern "carica e spara"? Non mi è chiaro, ehm...
Ti diro'. A me e' successo di recente notare una lenta ed inesorable
decadenza di un programma ben strutturato in uno di tipo carica e
spara.
Si tratta di una web application, suddivisa in piu' pagine asp, che
utilizza le variabili di sessione per far transitare dati da una
pagina all'altra.
Poi, alcune di queste pagine, contengono delle procedure di
validazione o altro, che per analisi svolta a suo tempo e per mia
personale pretesa, fanno largo uso di funzioni che ricevono i
parametri, e non fanno assolutamente uso delle variabili di sessione.
E questo ha funzionato per qualche anno, finche', modifica dopo
modifica, sono arrivati a richiedere che il programma facesse anche il
caffe', che non era stato analizzato all'inizio, e, in quella
particolare situazione, tra il prevedere il parametro in piu' (il
caffe') in una ventina di funzioni di validazione, o l'andarlo a
leggere direttamente dalla nuova variabile di sessione solo laddove
serviva, si scelse, per una mera questione di tempo e di costi, la
seconda soluzione.
E fu il principio della fine.
Da allora ogni successiva modifica con nuove richieste e nuove
variabili di sessione, porto' giocoforza tutte le funzioni di libreria
ad interrogare direttamente le variabili di sessione, trasformando il
tutto in una robaccia "carica e spara" che per mia fortuna non ho piu'
in gestione.

 spara.
Questo lato della cosa non l'avevo considerato :-)
Cioč che i programmi invecchiano (e alla fine, suppongo, muoiono) sotto 
il peso delle modifiche richieste e apportate nel tempo...
C'era un articolo tempo fa su un numero di Computer Programming dal 
titolo "il refactoring, prima o poi, arriva" e adesso capisco perché.
Grazie per l'insight :-)

 richieste e apportate nel tempo...
io ne ho ri-scritto uno per sei-volte-sei. Le prime
quattro facciamo tranquillamente che era
inesperienza e incomprensione dello spazio del
problema per così dire. Ma anche dopo tutte le
malizie su quel tema specifico, niente da fare, due
riscritture ci stanno tutte.
ciao!
Apx.


 bisogna farlo PRIMA di chiamare le funzioni che le usano.
Dipende dal linguaggio che usi. In generale, dal mio punto di vista le
variabili globali veramente globali sono essenzialmente roba che viene
da ambiente, linea di comando e files di configurazione. Questa roba e'
essenzialmente const.
In C++ e' davvero const. RAII garantisce che siano inizializzate e
distrutte al momento corretto. Eventualmente si puo' anche fare in modo
che siano li *prima* del main, in modo piuttosto facile.
Piattaforme piu' moderne tendono ad offrire strumenti appositi. 
-- 
-riko