Newsgroup: it.comp.dotnet
Titolo: [C#] Sconsigliata la notazione ungherese

Perchï¿œ Microsoft scoraggia la notazione ungherese?
A me personalmente piace, magari un po' ridotta.
Ma scrivere "sClienti" al posto di "Clienti" mi fa capire che sto 
lavorando con una stringa, scrivere "nValue" al posto di "Value" con una 
quantitï¿œ numerica e cosi via.
Grazie Ferradini

ferradini wrote:

Io ti dico la risposta che ho trovato dentro di me: perche' il nome di
per se dovrebbe farti capire con cosa hai a che fare.
Se chiami una variabile numeroClienti, sai con buona approssimazione
con che tipo di dati hai a che fare, cosi' come ce l'hai se ne chiami
un'altra nomeCliente.
In effetti, una volta che ci fai l'abitudine, non e' che ne senti tanto
la mancanza. Personalmente, io sento un'altra mancanza notazionale,
ossia il modo di nominare le variabili membro di una classe. Un tempo,
si usava m_ davanti e sapevi di che si trattava; ora, e' una pratica
deprecata. Personalmente, io ci metto un bel this. davanti e risolvo.
-- 
Ciao!
Luca


Sottoscrivo quanto detto da Luca e aggiungo che grazie ai metadati del 
framework, le informazioni sul tipo sono "facilmente" disponibili negli 
IDE. Il risultato ï¿œ che l'intellisense viene (quasi) gratis e quella 
naming convention diventa superflua.
CIao
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 Perch� Microsoft scoraggia la notazione ungherese?
Pensa a me che devo mantenere un'enorme code base scritta in c++ con la
suddetta, ed ogni volta che scrivo del codice per poter passare la code
review devo tornare indietro ad aggiungere questo residuato degli anni '70
...
-- 
ale
http://ale.riolo.co.uk

 deprecata. Personalmente, io ci metto un bel this. davanti e risolvo.
LOL, come si vede che non usi ReSharper :p
-- 
ale
http://ale.riolo.co.uk
 

 
E se dovessi stamparti una routine\classe da leggere su foglio? Come
faccio a sapere al volo il tipo e\o scope degli oggetti, variabili che uso?
La notazione ungherese è un attributo del codice e non dell'IDE per cui
in teoria rimane valida anche su .Net (magari nella sua versione
ristretta e non estesa).
Che poi nella pratica usiamo solitamente leggere il codice nell'IDE e
quindi non abbiamo bisogno della notazione ungherese per sapere il tipo
e\o scope delle variabili è un altro discorso!
Ma non c'era bisogno di arrivare a usare visual studio. net per giungere
a questa determinazione perché già visual studio 6 dava la possibilità
di conoscere il tipo e\o scope delle variabili senza bisogno della
notazione ungherese (se non ricordo male SHIFT + I).
Il fatto che sia ora deprecata secondo me è una delle solite "mode" che
usualmente si insinuano nel mondo dell'informatica senza una vera logica
sostanziale.
Questo non toglie che personalmente sono anche d'accordo nel ritenere
non necessaria la notazione ungherese.
;-)

 sostanziale.
in realtà (ma bisogna essere pignoli) non è questione di "moda", ma di 
semantica: la maggior parte dei compilatori .NET (nonchè la totalità di 
quelli che MS rese disponibili in v1) è dedicata a linguaggi OO, e 
quindi le naming guideline furono create pensando ad essi.
In OO, ogni oggetto è potenzialmente una istanza di tipi differenti, 
quindi la notazione ungherese non è, semplicemente, sufficientemente 
espressiva per esprimere la reale natura di un oggetto. Un esempio: il 
simbolo iCodiceElemento potrebbe affermare che l'oggetto è di tipo 
"intero", ma ometterebbe il fatto che esso è anche una istanza di: 
IComparable, IConvertible, IEquatable, IFormattable, ValueType ed Object.
Ok, metto in "off" la modalità "pignolo" :-)
-- 
.A
GUISA - 
http://www.guisa.org
UGIdotNET - 
http://www.ugidotnet.org
Read my blog at: 
http://blogs.ugidotnet.org/pape

 Ok, metto in "off" la modalità "pignolo" :-)
Perché non vedo IQuerable<T> o IEnumerable<T> ??? :)
GG


perchè per "accorciare" la lista non ho indicato le versioni generiche 
(che, effettivamente, sono dei tipi differenti). Sei più pignolo del 
sottoscritto: buono a sapersi :-)



Programmo al 90% in c++ e vengo dal mondo win e mfc. Anzi per molte cose 
lo uso ancora moltissimo (ho ancora alcuni progetti importantissimi e 
enormi in VS6.0!)
Posso essere d'accordo per il tipo.
Anche se confesso che per gli interi preferisco ancora anteporre una i o 
una dw per distinguere il caso con o senza segno... Mi aiuta ad evitare 
pericolosi mescoloni (assieme al warning level 4)
Quando uso c++ unmanaged mi piace anche usare s o sz davanti alle 
stringhe per distinguere le stringhe di "libreria" dalle stringhe C. Ma 
capisco che in C# questo significhi poco...
Magari crea confusione in c++ mixed, ma qui ci hanno pensato i ragazzi 
della MS che praticamente col VS2010 lo hanno cassato #@#@#!ï¿œ$%]!
Ma assolutamente non sono d'accordo per lo scope.
preferisco 10 a 0 m_ per i membri di istanza, s_ per i membri statici e 
g_ per i globali in c++ (oddio meglio non usare globali, ma se proprio...)
E il vantaggio IMHO viene proprio fuori con l'intellisense: i membri te 
li ritrovi tutti belli raggruppati, scrivi m_ e ce li hai tutti li 
comodi comodi. E non fai casino con eventuali argomenti di funzioni con 
lo stesso nome...

 LOL, come si vede che non usi ReSharper :p
Per me il codice deve essere chiaro anche se lo apro con Notepad.
-- 
Ciao!
Luca

 nome...
L'intellisense non fa molta differenza con C#.
Se proprio non ï¿œ necessario non uso il field privato direttamente, 
anche perchï¿œ puï¿œ portare a bruttissimi bug.
Esempio:
public string Name {get; private set;}
Se devo assegnare name ovviamente qui usi Name e sei a posto.
Se invece devi implementare la INotifyPropertyChanged (sento la 
mancanza di un attributo che dica al compilatore di implementarlo lui) 
devo fare:
private string _name;
public string Name
{
  get {return _name;}
  private set {_name = value; OnPropertyChanged("Name"); }
}
In questo caso uso Name obbligatoriamente anche da dentro la classe, 
altrimenti l'evento propertychanged non viene chiamato e sono guai 
seri.


 Magari crea confusione in c++ mixed, ma qui ci hanno pensato i ragazzi della MS che praticamente col VS2010 lo hanno cassato #@#@#!ï¿œ$%]!
Se vuoi provo ad essere meno criptico:
prova a fare un progetto c++/cli con VS2010 e a schiacciare alt-spazio.
Guarda bene nella status bar in basso a sinistra, piccolo piccolo vedrai 
spuntare questa bella frase:
"Intellisense: 'Unavailable for C++/CLI'"
googlala e ...
... su 
http://connect.microsoft.com/VisualStudio/feedback/details/459187/intellisense-unavailable-for-c-cli
 
scoprirai che alla MS hanno tolto l'intellisense apposta e non si 
capisce se e quando lo rimetteranno...
senza parole!
Ne sai qualcosa?

 Ne sai qualcosa?
Ah ok, adesso ï¿œ chiaro ...
ï¿œ un noto punto dolente per cui la maggioranza degli MVP ha protestato.
Il motivo ï¿œ semplice: tempo. La lista delle prioritï¿œ ha fatto slittare 
questa fondamentale feature.
Il team lo sa bene e per quanto mi riguarda continuerï¿œ a stressarli 
finchï¿œ non cedono :)


 finchï¿œ non cedono :)
Ok, conto sui di te :)
(fin'ora me la sto cavando splittando i progetti in due: c++ unmanaged 
col nuovo intellisense che funziona benissimo, e c++/cli per fare 
stupidissimi wrapper verso C# con codice praticamente boilerplate... 
perï¿œ non so quanto riuscirï¿œ a sopravvivere. )

 riuscirï¿œ a sopravvivere. )
Faccio anch'io cosï¿œ, anche perchï¿œ i debugger visualizer in CLI sono 
quasi inutilizzabili


ehm...quale notazione e guideline consigliate di usare?
"Andrea Saltarello"  ha scritto nel messaggio 
news:ia3s0g$46q$1...@tdi.cu.mi.it...
