Newsgroup: it.comp.lang.visual-basic
Titolo: OT notazione ungherese

salve,
siete tuti cosi' contrari alla notazione ungherese nella nomenclatura delle
variabili??
in Net le specifiche di codifica lo sconsigliano caldamente (perche' tutto
e' un oggetto??) ma personalmente sono pieno di iLoop, iCount, sBuffer,
sNome, curValuta etc...
ammeto di essere anche pieno di "i", "x", "l" etc, ma la notazione ungherese
mi dava subito l'idea di come avevo dichiarato la variabile senza dover
scorrere il codice fino alla dichiarazione per vedere se Conto e' un oggetto
Conto oppure un currecy Conto (curConto) o se Persone e' una collection di
oggetti Persone o un Long utilizzato per calcoli statistici....
commenti??
Andrea Montanari
montanar...@virgilio.it
http://utenti.lycos.it/asql/index.html
(my vb6+sql-dmo little try to provide MS MSDE 1.0 a visual interface) ver
0.0.46
--------- remove DMO to reply

 sNome, curValuta etc...
Uhmmm... Argomento difficile da affrontare in "poche righe", ma
proviamoci... :-)
La realtà dei fatti è che la notazione ungherese è "semplicemente" poco
adatta alla OOP in genere, e di conseguenza in .NET (dove anche i tipi
concreti si presentano come classi). Ti faccio un esempio: consideriamo una
classe che implementa 2 interfacce...
Interface IMiaInterfaccia
    Sub M1()
End Interface
Interface IMiaInterfaccia2
    Sub M2()
End Interface
Public Class MiaClasse
    Implements IMiaInterfaccia
    Implements IMiaInterfaccia2
     '...implementazione delle interfacce
End Class
Quale prefisso useresti per le sue istanze? Non certo uno che "qualifichi"
la classe, poichè due istanze potrebbero essere riferite ad interfacce
differenti ed avere lo stesso prefisso, il che sarebbe ambiguo. Nemmeno
utilizzare un prefisso che "qualifichi" l'interfaccia non è una soluzione,
perchè una interfaccia (letteralmente parlando) _non_ è un tipo... E allora?
Allora, in contesti OOP tipicamente si usa la notazione "Camel Case", che si
focalizza semplicemente sul "concetto" rappresentato dal simbolo. Per
esempio:
Dim elencoFatture As DataTable
DataTable elencoFatture;
sia in 
VB.NET
 sia in C#.
sul nostro sito (se ti può interessare) nella sezione "Goodies" trovi
informazioni e link ad un tool di Microsoft che "testa" un assembly .NET
sulle regole di stile consigliate. Si chiama FxCop.
.A
UGIdotNET - 
http://www.ugidotnet.org

 concreti si presentano come classi).
Credo sia più una questione di gusti.
Io uso la notazione ungherese comunque (per le variabili private), anche
perchè un Int32 pur essendo una classe è ben diverso da un ArrayList.
Anche perchè spesso capita di avere nella stessa sub iArticolo e
objArticolo.
Poi ci si può anche sbizzarrire :) es. se un ArrayList contiene stringhe
potrebbe essere chiamato a_sPersone piuttosto che a_iNumeriPrimi.
Ciao
--
' // Initialize the expression evaluator
Engines.Evaluator = CreateObject("
http://www.neodatatype.net
")
' // you can find resources for and from the NG here!
Me.SitoComune = "
http://www.it-lang-vb.net
"

variabili??
Imho l'unica cosa veramente utile e' un prefisso che indichi
l' ampiezza dello scope delle variabili.
Io uso spesso, quale che sia il linguaggio in questione,
i seguenti (che faccio o no seguire da un _):
g			= visibilita' globale;
m			= membro di classe, visibile a tutte
				le procedure della classe;
mi oppure niente	= membro interno della procedura;
a			= argomento ricevuto nella chiamata 
				a funzione;
p			= puntatore
Inoltre scrivo in tutto maiuscolo i valori costanti;
In questo modo mi rendo subito conto della portata
delle eventuali modifiche apportate al contenuto
della variabile.
Trovo invece pernicioso l'uso di prefissi indicanti il
tipo perche':
- se si deve cambiare il tipo si e' costretti anche
  (per coerenza) a modificare il nome della variabile;
- un handle sara' sempre numerico cosi' come un contatore,
  mentre un nome di persona sara' una stringa ;-)
- introduce lavoro extra nel passare il codice da un
  linguaggio all'altro;
-- 
ciao, hal




 statistici.... commenti??
Semplice. Se le variabili hanno nomi significativi, le funzioni
la giusta lunghezza, e si utilizzano variabili globali solo
quando strettamente necessarie (ovvero quasi mai), non c'è
nessuna necessità di utilizzare la notazione ungherese, che, per
chiarire, non migliora affatto la leggibilità se non a livello
personale (= si comprende ancora meno il codice scritto da
altri). 
L'unica notazione che io utilizzo è aggiungere un _ alla
fine dei nomi dei membri privati di una classe, per
evitare"collisioni" di nomi tra gli stessi e parametri di
costruttori, funzioni, ecc...
Ciao.
-- 
BSD is for UNIX lovers - linux is for Windows haters

 allora? 
Anche utilizzare la I per indicare che si tratta di un
interfaccia è sintomo di nomi poco significativi... e da
evitare.



ciao.


 convenzione.
Si tratta appunto di una convenzione, non di un obbligo...
L'importante è scrivere il codice nella maniera corretta, non
seguire le convenzioni di un ambiente di sviluppo.


 periodo iniziale, si rivela decisamente + adatta a contesti OO.
Sicuramente se le variabili fossero usate con nomi significativi sarebbero
più chiare, ma questo è assolutamente indipendente dal Camel Case.
Io posso anche usare il CC con la not. ungherese: sCodiceArticolo o
addirittura strCodiceArticolo.
zanna.ormainehavistetante(chenonsistupiscediniente, sonosologustipersonali)
Ciao


 .NET, il quale utilizza questa convenzione.
E perchè dovrei seguire una convenzione che si contraddice da sola? :P
La devo seguire per forza anche se è fatta male? :)
Ciao

 Ciao
ciao!

 indipendente dal Camel Case. 
Ma non lo è dal seguire un corretto stile, che non può essere
solo personale.
Ciao da un HPL al quale è morta la macchina win2000 e fa fatica
a trovare un newsreader del valore di Outlook Express...


 atteggiamento "difensivo", quando non c'è stato alcun attacco... :-)
Immagino che sia colpa del caffè :-). Prendi me, non ne ho ancora
preso, e al post "CODICE SORGENTE", tutto in maiuscolo, subject
compreso,  ho dato una risposta calma e tranquilla... se mi capita
un post simile tra un'oretta, lo massacro.
Un Paperino "...giusto il tempo che la caffeina faccia effetto >:-|"

 più chiare, ma questo è assolutamente indipendente dal Camel Case.
Però è singolare che proprio la casa produttrice sia la prima a non
rispettare le sue stesse regole :)
Ciao