Newsgroup: it.comp.lang.visual-basic
Titolo: cicli for each...next

 vedi sopra, prime 3 lettere per indicare in tipo di ogetto sempre
minuscole
OK.
Diciamo che tu previeni il problema con una rigida disciplina nei nomi.
Tuttavia, può accadere che sul tuo software ci metta mano qualcun altro, o
che tu abbia il capslock attaccato e inavvertitamente ti scappi una
maiuscola, o che (e questo purtroppo accade), tu debba sostituire un textbox
con un altro controllo, ma che per motivi vari (ad esempio per non dover
riscrivere del codice che è compatibile con il nuovo controllo), tu decida
di lasciare il nome originale 'txtpippo' anche al nuovo controllo.
Altra opportunità, è che tu debba mettere mano al codice dopo 5 anni, e che
tu nel frattempo abbia cambiato leggermente stile di scrittura, ad esempio
usando le maiuscole nei nomi dei controlli (se tu venissi a lavorare nella
mia ditta, ad esempio, i controlli con nome minuscolo non te li passo
proprio. Almeno una maiuscola ci vuole per poter verificare la correttezza
del nome con l'intellisense).
In sostanza, tu escludi un problema perchè sostieni di prevenirlo alla
fonte. Io ti consigliavo (e te lo consiglio comunque), di utilizzare una
metodica di individuazione del controllo che fosse indipendente dal Case del
nome, e che usasse TypeName anzichè affidarsi al rigore del nome.
E' un po' come quando si controlla che una variabile sia diversa da zero
prima di fare una divisione. Anche se, per come la variabile viene popolata,
il suo valore non potrà mai essere zero, il controllo va comunque fatto,
perchè nell'evoluzione del software non sai mai come le cose cambieranno.
Ciao
Alberto

 perchè nell'evoluzione del software non sai mai come le cose cambieranno.
Si e' logico, non escludere mai nulla e' la fase + delicata nella
programmazione , ma e' quella che ti fa ridurre di molto i tempi di
debugging
cmq il tema portante del mio post era di ricercare ogniuno delle regole
personali e pubbliche e di rimanere coerenti ad esse il + possibile e per +
tempo possibile !
Cioe', diciamo che a scuola ho appreso le basi per le mie regole, poi le ho
sviluppate e adattate a me e soprattutto ho cercato di rimanere il +
allineato possibile con gli esempi che trovavo, l'unica pecca e' che uso
poco le REM e a volte anche se il codice e' di facile lettura , non riesco a
comprendere in pieno il senso di una sub ^_^ Specialmente quando usavo il
copy&paste senza modificare nulla e avevo un valore che passava tra 3 - 4
sub e ogni volta cambiava nome !
eh eh , in conclusione ognuno programma da solo come gli pare ma dovrebbe
cercare di imporsi delle regole o consuetudini e cercare di rispettarle il +
possibile!
nei workgruop invece e' tutto un calvario... emm volevo dire che dovremmo
cercare di acquisire una elasticita' tale da permetterci di spaziare in
tutto il codice con estrema fluidita' , lo so che do consigli quasi scontati
, ma credo che uno scambio di idee sia la cosa migliore per migliorarsi , e
poi : "chi non cambia mai idea e' uno stolto" (wild cit.)

 possibile!
Certo.
Il punto del mio post era:
Tu hai postato del codice in cui l'uso di maiuscole o minuscole
comprometteva il corretto funzionamento, e se ci fosse stato un controllo
diverso da un textbox con nome txt... il programma si piantava.
Ti ho fatto presente che il codice postato da me utilizzava metodiche che
garantivano il corretto funzionamento anche se ci fosse stata una maiuscola
al posto di una minuscola, e evitavano il crash se un controllo di tipo
diverso dal textbox avesse avuto un nome del tipo 'txt....'.
Tu hai detto che queste precauzioni non ti servivano, perchč eri certo che
tutti i nomi iniziassero con txt minuscolo, e che nessun controllo diverso
dal textbox veniva chiamato txt....
Io ho spiegato che, IMHO, fidarsi della disciplina nel dare i nomi, per
garantire il funzionamento del codice, non č un metodo robusto di scrivere.
Ho portato alcuni esempi, ovviamente non esaustivi, perchč queste cose si
presentano sotto le piů disparate forme.
Poi, come tu dici, ognuno č libero di 'codare' come vuole.
Ciao
Alberto

 garantire il funzionamento del codice, non è un metodo robusto di
scrivere.
Si , grazie del riassunto, ho capito la tua tecnica e devo dire che *per me*
sarebb davvero troppo sconvolgente passare ad essa, cmq rileggendo i vecchi
post del 3ad su google devo dire che e' ottima !