Programmazione.it v6.2
Ciao, per farti riconoscere devi fare il login. Non ti sei ancora iscritto? Che aspetti, registrati adesso!
Info Pubblicità Collabora Autori Sottoscrizioni Preferiti Bozze Scheda personale Privacy Archivio Libri Corsi per principianti Chat Forum
Alcuni pareri sull'utilità della notazione ungara nella programmazione
Scritto da Francesco Argese il 16-11-2009 ore 10:48
La notazione ungara, o notazione ungherese (dall'inglese hungarian notation), è una convenzione adottata nella programmazione e riguarda il nome da attribuire agli oggetti definiti nel proprio codice; essa consiste nell'includere, nel nome degli oggetti (ad esempio con un prefisso), informazioni come il tipo e la visibilità dell'oggetto stesso. Tale notazione deve il suo nome alla nazionalità del suo creatore, Charles Simonyi, noto per aver lavorato ad alcuni dei più importanti progetti di Microsoft.

Esistono pareri discordanti circa l'utilità di tale tecnica nella programmazione object-oriented. C'è chi ne comprende l'utilità per taluni linguaggi di programmazione (C++ in primis) e chi invece non riesce a coglierne alcuna utilità o, addirittura, la considera una tecnica che crea problemi nelle fasi di scrittura del codice.

In particolare Robert Oslow ha scritto che la notazione ungara, pur non essendo utile in un linguaggio puramente ad oggetti, può tornare utile in un linguaggio come C++ — che non è un linguaggio ad oggetti puro — per specificare, nel nome degli oggetti, se un membro di una classe è privato, statico, o altro; per citare un esempio, MFC utilizza come prefisso al nome degli oggetti m_ per un membro, c_ per un membro statico.

Le critiche alla notazione ungara sono rivolte al suo utilizzo per specificare il tipo degli oggetti. Al riguardo Linus Torvalds ha scritto: "Il compilatore conosce comunque il tipo e lo può verificare, e l'unica cosa che fa la notazione ungherese è confondere il programmatore". Bill Davis ha, invece definito la notazione ungara un metodo che preclude la possibilità di portare il codice da una piattaforma a 16 bit ad una a 32 bit.

Infine Robert C. Martin ha affermato di non considerare utile la notazione ungara per i linguaggi fortemente tipizzati; in tali casi, essa sarebbe ridondante e aumenterebbe semplicemente la complessità. Secondo Martin, essa è una tecnica per commentare il codice, ma la sintassi dei commenti non è controllata dal compilatore e quindi non è detto che essi siano accurati.
Precedente: Bada, il nuovo sistema mobile di Samsung
Successiva: SugarCRM, un software open source per il customer relationship management (1/3)
Commenti:  Primi  «  Meno recenti  «  11 - 12 di 12
Intervento di Fabio Vianello a.k.a. fabiovianello del 17-12-2009 ore 09:09, Poiana maggiore (VI)
Barone
Barone

(234 interventi)
Iscritto il 30-05-2008
guidobilli ha scritto:
fabiovianello ha scritto:
Interessante anche questo link in cui si può apprezzare alcuni motivi per cui utilizzare la notazione ungara.


Notazione ungara e Java.

Se si allarga la definizione di notazione ungara come fa l'autore, per definizione ci puo' cascare dentro tutto.

>> Is this Hungarian Notation? I think it is, at least in
>> the sense that it makes the code clearer

Che io sappia la notazione ungara richiede che ci sa un prefisso che indica il tipo [e volendo lo scopo della variabile] come fanno le DirectX.
Nei suoi esempi questo non succede.
Altrimenti avrebbe dovuto chiamare le variabili sInput e sOutput o semmai streamInput e streamOutput.

Secondo me quella suggerita nell'articolo e' banalmente l'introduzione di una convenzione nei nomi che non e' la notazione ungara, in quanto risulta essere una pratica che io stesso (e molti altri che programmano) applico autonomamente seguendo un minimo di buon senso nel dare i nomi, ma che non dipende dal tipo, ma da cosa quella variabile rappresenta. Come ad esempio:

inputFile
recordList
messageTable
userInfo
accountManager
ecc...

questi nomi riflettono l'identita' di cio' che sto manipolando, e non il tipo specifico dell'oggetto che li rappresenta in memoria. In alcuni casi lo stesso nome puo' anche rappresentare il tipo (un file e' un file, c'e' poco da fare), ma e' un caso.

Esatto, chiarisco meglio, come tante altre cose in informatica le si possono adattare al contesto in cui si utilizzano e l'articolo ne è un esempio. Ed era quello che mi interessava far notare. Spero di essere stato chiaro ora.
E questo se mi permetti non è banale come il senso dell'articolo.
Intervento di Fabio Vianello a.k.a. fabiovianello del 17-12-2009 ore 09:20, Poiana maggiore (VI)
Barone
Barone

(234 interventi)
Iscritto il 30-05-2008
Altro contributo
Citazione:
Function overloading and Hungarian notation
ANSI C does not support function overloading. Function overloading is a requirement for inheritance and polymorphism. The trick to achieving function overloading to utilize Hungarian Notation.

Hungarian notation is the use an acronym, that signifies the data type of a given variable, as a prefix on that variable name. For example, the variable 'count' of type unsigned short would become 'usCount'.

In C-Objects, Hungarian notation is extended 2 ways. First, the acronym transends the simple data type and becomes the object type, and secondly, the acronym prefix is also used on the object's member functions to achieve pseudo function overloading.

An example is the getNext() function. Of the C-Objects in this directory, The getNext() function exists in the cursor of the BitArray, the List and RAMpool. By using Hugarian notation, the 3 forms of getNext() become:

BAcursor: baGetNext( BAcursor * ) // see line 155 in bitUI.c
pListCursor: pGetNext( ListCursor * ) // Pointer List
RPcursor: rpcGetNext( RPcursor * )

These 3 forms of getNext() show how Hungarian notation can be used to achieve function overloading for what essentially is the same functionality on 3 different collection types. The use of the same function name for similiar member functions the provide the same functionality to similiar objects at compile time is sometimes call weak polymorphism.

Strong polymorphism, where the appropriate member function is determined at run time by the object type, requires virtual functions, which is too complex for C-Objects.

Come vedi un estensione ...
Commenti:  Primi  «  Meno recenti  «  11 - 12 di 12
Copyright Programmazione.it™ 1999-2009. Alcuni diritti riservati. Testata giornalistica iscritta col n. 569 presso il Tribunale di Milano in data 14/10/2002. Pagina generata in 4.681 secondi. Sito ottimizzato per Mozilla Firefox. Powered by Kyron.