Newsgroup: it.comp.lang.visual-basic
Titolo: [OT] succede, nel mettere mano al codice degli altri...

ho messo mano a del codice scritto da altri e non capivo perche' 
rinominando alcune variabili (mi piacciono di piu' con un nome diverso), il 
programma non andasse in errore e si compilasse ugualmente (non ho provato 
a farlo partire, sai mai...).
sono fissato con option explicit e mi aspettavo valanghe di segnalazioni.
guarda e riguarda, ho scoperto l'arcano.
la pensata e' stata geniale: una variabile 'pippo' dichiarata globalmente e 
poi in ogni procedura in cui serviva una variabile dello stesso tipo, una 
nuova variabile, con lo stesso identico nome di quella globale, dichiarata 
localmente.
geniale, vero?
adesso mi spiego anche alcuni dei comportamenti 'bizzarri' 
dell'applicazione...
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 geniale, vero?
Già un programma -di qualsivoglia dimensione- con una variabile di nome 
pippo ... è da guardare con occhio critico ...
ma -se può consolarti- si è visto di peggio,
programmi dove tutte le variabili parevano tirate fuori pari pari da un 
fumetto di Disneiana memoria.
Programmi dove una che una label o texbox avesse un nome significativo, 
e non programmini di 5 o 6 controlli.
è pratica piuttosto diffusa ... purtroppo.
ciao
stefano

 wrote in
news:486a3ffb$0$17941$
5fc...@news.tiscali.it
: 

il 'pippo' era solo un nome tanto per dire.
effettivamente le variabili si chiamano:
- myValue
- myQuery
- myImageUrl


 - myImageUrl
il risultato finale però non cambia, però
almeno Topolinia non viene messa in mezzo :)
ciao
stefano

 wrote in news:486a4757$0$17933$5fc30a8
@
news.tiscali.it
:

he...
sapessi che consolazione!!
:-)


 localmente.
Bhe se è dichiarata localmente fa fede quella ovviamente, e lascia stare la
globale.
Questo se si hanno moduli globali con variabili pubbliche può succedere, ma
alla fine non è che incasina tantissimo.
Io mi incasino di più con i nomi delle routine poco intuitivi, o con le
routine troppo spezzettate (es. un mio ex collega, per fare una procedura,
ha spezzato tipo in 12 routine, quando imho ne bastavano 1/3 al massimo,
tra l'altro routine specifiche senza riutilizzabilità, o comunque usate
solo una volta. Ne incollo un paio:
Private Sub EsportaRicetta__Ph(Ph As String)
    EsportaRicetta__FlPh = Ph	'setta una var privata del modulo
End Sub
Private Sub EsportaRicetta__Cu(Cn As Long)
    Close #Cn	'chiude un file aperto chissà dove :)
End Sub
Immaginatevi quando devo trovare il "cuore" dell'elaborazione :)

 - myImageUrl
Non resta che aggiungere:
myGod
--
Ciao!
Maurizio Borrelli [Microsoft MVP Office System]
http://www.riolab.org/

 - myImageUrl
si atteneva strettamente agli standard ms, se hai presente le cartelle
che crea windows, MyMusic, MyDocuments, MyEBooks :P
che, btw, e' geniale davvero, in sistemi in cui il 'my' dei dati e' o
dovrebbe essere implicito nel profilo utente...
ciao, a.

 
programmazione creativa?
:-)


Parlando in generale, questo è un tipico caso in cui, a mio avviso, si
evidenzia l'errore che Microsoft commette nelle nuove linee guida di
denominazione dei nomi .Net, quando afferma che non è necessario
specificare lo scopo (ed il tipo) della variabile...


Quella della nomenclatura è/era un puro supporto "di lettura", non la
soluzione: gli unici colpevoli storici di queste situazioni sono (la
mancanza di) Option Explicit e il Variant come tipo di default
Grazie al cielo in 
VB.NET
 il Variant non esiste piu' e Option Explicit
è sempre ON per default (fosse per me l'avrei proprio eliminato), in
più puoi ulteriormente controllare la correttezza formale dei tipi con
Option Strict; a questo punto il lavoro di bassa manovalanza lo fa il
compilatore, e anche l'ide, e cose come quella descritta sono
stroncate sul nascere.

 tutto evitabile utilizzando nomi diversi a seconda dello scope.
No, quello ti avrebbe solo salvato in corner quando hai preso in mano
tu il codice; era *tutto* evitabile sin dall'origine usando Option
Explicit.
Se "gli altri" dovessero parlare con un confessore, meriterebbero un
paio di "ave" per aver usato nomi uguali e una sprangata nelle gengive
per la dichiarazione non obbligatoria ;-)

 mancanza di) Option Explicit e il Variant come tipo di default
Si! hai perfettamente ragione dal punto di vista della tecnica di
programmazione. Il mio intervento, però, voleva avere uno scopo
diverso e sicuramente è connotato da un approccio più "filosofico" che
tecnico: penso che, nel momento in cui si permette al programmatore di
scegliere che "Option Explicit" sia opzionale (lascia stare poi se per
default è On o Off), non si possano poi stilare delle regole di
denominazione che non prevedano l'indicazione di almeno 2 lettere in
più, una per l'ambito di visibilità ed un'altra per il tipo. Il fatto
di specificare che non ci sia necessità di specificare il tipo o lo
scopo, presuppone che in Microsoft si pensi che comunque utilizzeremo
sempre il loro IDE di sviluppo(quindi con CTRL+SHIFT possono vedere
tipo e scopo)  e non capiterà mai di dover stampare un listato di
codice per effettuare valutazioni lontano da un computer.
Ciao.

 per la dichiarazione non obbligatoria ;-)
seeeeeeeeeeee bona và!
vuoi mettere la complicazione di scrivere
dim pippo as string
lo sai che sono 1 2 3...19 movimenti di polpastrello?
lo sai che sono 0.0025 calorie???
Se poi devo pure mettere Public o Private
sono altre 0.014 calorie per i neuroni che ci pensano e assorbono
zuccheri!
ma sei impazzito???
ma quanta fatica fai a scrivere i tuoi programmi!
Molto meglio un bel spaghetti-code!!!
...casomai condito con una bella "pomarolina"(lo dico alla toscana)
con il basilico fresco!
yum!

 wrote in
news:da0fb118-c4c4-4da7...@c65g2000hsa.googlegroups.com
: 

option explicit era ed e' attivo.
se nome e tipo coincidono, option explicit non aiuta, perche' la 
variabile effettivamente e' dichiarata.
Option Explicit
public class clsAccrocchioPauroso
    	dim variabile as string
    	public sub funzioneEsagerata
    	    	dim variabile as string
    	    	variabile = "ciao mondo!"
    	end sub
    	public sub funzioneMeglioDiPrima
    	    	'dim variabile as string
    	    	variabile = "saluti e baci"
    	end sub
end class


 wrote:
zac
mmm...spetta!
ora tu stai parlando di VB.net!
Allora bisogna distinguere!
La cosa ha un "certo" senso....
te l'ho riscritta in questo modo:
Public Class clsAccrocchioPauroso
    Dim Variabile As String = "TEST 123"
    Public Sub funzioneEsagerata()
        Dim Variabile As String = ""
        Variabile = "ciao mondo!"
    End Sub
    Public Sub funzioneMeglioDiPrima()
        'dim variabile as string
        Variabile = "saluti e baci"
    End Sub
    Public ReadOnly Property miaVariabile() As String
        Get
            Return Variabile
        End Get
    End Property
End Class
La uso così in un form dentro un button
Public Class frmTest
    Dim TEST As New clsAccrocchioPauroso
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
        TEST.funzioneEsagerata()
        MsgBox("FunzioneEsagerata: " & TEST.miaVariabile)
        TEST.funzioneMeglioDiPrima()
        MsgBox("Funzione meglio di prima: " & TEST.miaVariabile)
    End Sub
End Class
Ora...chiamarlo errore non ha senso....
cosa faccio? uso una variabile  per trattenere per tutta la classe il
valore di una proprietà
è lo stesso sistema che fa il code snippet
vuoi una nuova proprietà?lui ti scrive.....
Private newPropertyValue As String
Public Property NewProperty() As String
    Get
        Return newPropertyValue
    End Get
    Set(ByVal value As String)
        newPropertyValue = value
    End Set
End Property
Ora.....
la confusione caso mai nasce dal voler chiamare DENTRO una routine(sub
o function) una variabile con lo stesso nome!
Non succede nulla...ma si potrebbe se non si è "scafati" essere
indotti a pensare che ANCHE la routine funzione esagerata imposti la
variabile!
E non è vero!
perchè quella dichiarata dentro MASCHERA quella fuori
dovresti fare così
    Public Sub funzioneEsagerata()
        Dim Variabile As String = ""
        Variabile = "ciao mondo!"
        Me.Variabile = Variabile
    End Sub
...prova...adesso "TEST 123" non appare più!
Si può fare confusione...sarebbe meglio non scriverlo perchè fra 3
mesi o fra un anno si dovrebbe essere in grado di modificare il codice
senza stare una settimana a pensare quello che si era scritto......
ma in 
vb.net
 si può fare....e trovo che non sia neanche un
errore....basta fare attenzione!
p.s.
L'esempio funziona...ho provato il codice prima di scriverlo
e c'è l'Option Explicit (che con queste cose non ci incastra nulla!)
Saluti!

 wrote:

Quando hai detto "sono fissato con option explicit " l'ho inteso come
"ce l'ho aggiunto io"; se era gia' attivo allora il tuo rinominare le
variabili non ha innescato comportamenti "strani" (che non ci fossero
gia' prima, almeno)
Io immaginavo la situazione come quella del tuo esempio ma senza O.E.;
in quel caso aggiungendolo non ti avrebbe dato alcun errore di
compilazione ma non avresti avuto modo di sapere se l'intenzione di
funzioneMeglioDiPrima() era usare una variabile locale non dichiarata
oppure davvero quella di scope piu' alto...

 Ciao.
Scusa, ma non sono affatto d'accordo, né sul fatto di specificare il 
tipo di una variabile né il suo ambito di visibilità sotto forma di 
prefissi al nome vero e proprio.
La c.d. Notazione Ungherese, perché così si chiama, ha perso la sua 
ragione d'essere già da tempo. Il motivo è spiegato chiaramente nella 
relativa voce di wikipedia (
http://it.wikipedia.org/wiki/Notazione_ungara
)
Il fatto che venga ancora usato, ad esempio per le API di Windows, non 
vuol dire che rappresenti una buona pratica di programmazione.
Tuttavia, il motivo migliore per non usare tali prefissi è la difficoltà 
che si presenta non appena si decide di cambiare il nome di una 
variabile. Già di per sè valutare attentamente le implicazioni di una 
mossa di questo tipo è fortemente snervante: se ci mettiamo anche la 
scocciatura di adattare il prefisso, la possibilità di commettere errori 
aumenta.
Sul fatto poi di stampare una porzione di codice su carta... neanche qui 
la notazione ungherese aiuta: se le varie funzioni (nella fattispecie 
Sub e Function) sono scritte con criterio, rintracciare il tipo di una 
variabile non sarà così difficile o distraente, perché si tratterà di 
esaminare una piccola parte di codice per volta.
S.

 Saluti!
il problema che sto sperimentando io, e' proprio quello: devo mettere 
mano a del codice scritto da altri, dopo qualche anno e ovviamente dopo 
che il programmatore originale non e' piu' disponibile e variabili 
identiche per nome e tipo, in scope diversi, con nomi non significativi 
(i myquery, mystring, myetcetcetc, sono i nomi reali...) crea non poca 
confusione...


 confusione...
Trova il programmatore originale e riducilo orribilmente a brandelli.
Non risolverai il problema, ma almeno l'arte della programmazione ne 
uscirà un po' nobilitata.
BTW, ti capisco. Ho (in parte) lo stesso problema, che mi si ripresenta 
in maniera più grave ogniqualvolta devo mettere le mani su un certo 
programma.
Solo che lì, in aggiunta, la gran parte delle variabili è globale, non è 
usato da nessuna parte l'Option Explicit (quindi mi trovo con variabili 
tipo %X, %XX, buffer$), i vari form vengono aperti con un elegantissimo 
frmMain.Show, più di qualche routine fa le stesse cose 3 volte per 
nulla, istruzioni indentate in maniera non corretta, eccetera. Spettacolo.
La parte peggiore in casi come questi è, appunto, che più vai avanti e 
peggio diventa.
Nei ritagli di tempo sto riscrivendo di sana pianta una piccola parte 
alla volta, e continuerò così fino a che non avrò il tempo di buttare 
tutto nel water e tirare lo sciacquone e riscriverlo completamente. 
L'unica cosa che mi trattiene, a parte la mancanza di tempo, è che il 
programma fa pesante uso di un paio di DLL delle quali, almeno per 
quanto è risultato dalle mie prove, sotto .NET non si riescono ad usare 
le funzioni.
S.