Sinn und Unsinn der ungarischen Notation

rüdiger schrieb:

Tim schrieb:

Welche Alternative wird denn von den Kritikern vorgeschlagen? Welche wird benutzt?

Welches Problem willst du mit UN lösen? Dann sage ich dir meine Alternative dazu.

Ich verstehe nur nicht, was falsch daran sein soll einer (globalen) Variable z.B. das prä/postfix "angle" oder sowas mitzugeben. Halt einen Qualifier nach einer Konvention.

Edit: Als präfix finde ich das aber auch nicht toll.

asc

Ich gebe auch mal meinen Senf zu dem Thema. Meine Meinung nach ist die Ungarische Notation schon aus mehreren Gründen zumindestens in allen modernen OO-Sprachen völlig fehl am Platz. Das liegt zum einen daran das es eine unüberschaubare Anzahl an benutzerdefinierten Typen gibt, und das man an manchen Stellen die Ungarische Notation eh nicht einsetzen kann. Einziges Überbleibsel aus der Zeit ist bei mir noch das I vor einem Interface (und auch das wäre nicht nötig) und in C++ das p für Zeiger, auch wenn ich auch dort inzwischen von Abweiche.

Meine Gründe gegen die Ungarische Notation:

a) Die ungarische Notation erfordert das man noch eine zweite Sprache zusätzlich lernt (Die Kürzel sind zum Teil wirklich nicht lesbar wenn man sich nicht auch noch damit beschäftigt).
b) Moderne IDE's sollten den Typ eh erkennen.
c) Templates/Generics etc. lassen die ungarische Notation eh nicht sinnvoll zu
d) Wenn man den Typ einer Variable ändert, muss man auch das Kürzel anpassen, auch wenn die Bedeutung sich nicht ändert.

Ich bin eh der Meinung lieber aussagekräftige Bezeichnungen zu wählen, da es eh leichter zu lesen ist als irgendwelche kryptische Abkürzungen.

cu André

Artchi

Das einzige wo bei mir ein Typ mit in den Namen rein kommt, sind solche Sachen:

class SomeClass
{
    Teilenummer rechtesTeil; // aus der Automotive-Branche
    Teilenummer linkesTeil;

    Button okButton;

};

D.h. vieles kommt bei meinen Benamsungen aus der der normalen Sprache.

asc

Artchi schrieb:

...
D.h. vieles kommt bei meinen Benamsungen aus der der normalen Sprache.

Das finde ich auch ganz okay so...

Ein guter Programmierer schreibt Code für Menschen,
ein Schlechter für Computer

...den schließlich muß man Code meist häufiger lesen als schreiben. Und eine natürliche Sprache kann auch ein Anfänger gut verstehen.

cu André

Artchi schrieb:

Naja, Jester wollte eher sagen, das es komisch ist ein Datei rein zu schreiben. Eine Datei schreibt man eher raus.

ja, voll komisch. dateien sind doch nur zum lesen da, aber man liest sie nicht aus, sondern schreibt sie raus.

Artchi schrieb:

Wobei ich trotzdem die Namensgebung zu lang finde, da zu viele Wörter in dem Variablenname. out oder outfile würde auch reichen.

klar, out ist gut. warum nicht gleich nur 'o'? konsequent durchgezogen schont man damit das keyboard und spart platz auf der platte.

asc schrieb:

Ein guter Programmierer schreibt Code für Menschen,
ein Schlechter für Computer

deswegen gibt es auch so viele langsame und fette programme.

asc

nicht-UN-freak schrieb:

asc schrieb:

Ein guter Programmierer schreibt Code für Menschen,
ein Schlechter für Computer

deswegen gibt es auch so viele langsame und fette programme.

Wenn du dich damit mal nicht irrst. Ein Programm was zuerst einmal für Menschen geschrieben wird kann leichter optimiert werden als eines das für Computer geschrieben ist.

Zudem
a) Der Code lässt sich besser Warten und Refactorisieren
b) Man benötigt weniger Zeit für Fehler und Einarbeitung, so das mehr Zeit für das eigentliche Bleibt

Eine Optimierung verschlechtert zwar anschließend meist ein wenig die Lesbarkeit, die Optimierung sollte aber eh erst kommen wenn man herausbekommt das es an dem Codeteil liegt.

cu André

EXDW

also wenn ich hier mal wieder {eigentlich taeglich} code durchlesen, und ich wuerde nicht gleich erkennen obs eine member ist - und was fuer ein typ usw, ich wuerde durchdrehen - muesste ich alles viel aufwendiger durchsehen
"die ide sagt was es ist", ja, schon, wenn man die variable markiert oder mit der maus drueber bleibt - aber wenn man schnell mal wieder codezeilen durchscrollt und was sucht, finde ich das dann der {in der firma einheitlich gehantenen} UN deutlich schneller als das cih erst jedes objekt auf seinen typ hin analysieren muss
{bevor fragen aufkommen, ich arbeite in der lokalisierung, und bin dadurch application jumper, wir produzieren ~20 programme, von kleinen programmen bis hin zu sehr grossen, und ich muss staendig fremden code lesen}

CStoll

Artchi schrieb:

Ich benutze gar keine Notation. Sagen wir mal Member-Variablen. Ich schreibe nicht sowas:
class SomeClass
{
     wstring mws_name;
};
Nein, ich brauche kein m für Member und kein ws für wstring.
class SomeClass
{
     wstring name;
};
Wofür steht die Variable? Genau, für einen Namen. Der Typ kann sich aber jeder Zeit in ein u32string-Typ oder sogar in einen Typ PersonName ändern:
class SomeClass
{
     PersonName name;
};
Es ist IMMER im Kontext gesehen ein Name. Deshalb ändere ich den namen nicht auf mpn_name um.

Ich würde den vermutlich "m_name" oder "m_sName" (dabei steht das 's' nicht für einen konkreten Typ, sondern einfach für "etwas String-artiges") nennen.

Was interessiert mich der genaue Typ? Für die Lösung der gestellten Aufgabe muß ich mit einem Namen rumhantieren. Der _genaue_ Typ ist zweitrangig (nicht unwichtig!). Aber ich kann aus dem "name" semantisch wissen, das es eine Art Wort oder Zeichenkette sein soll. "name" kann schlecht eine Geschwindigkeit sein... z.B. vom Typ "int" oder vom Typ "Tempo". Dann hätte ich die Variable eher anders benennen sollen.

asc schrieb:

b) Moderne IDE's sollten den Typ eh erkennen.
c) Templates/Generics etc. lassen die ungarische Notation eh nicht sinnvoll zu
d) Wenn man den Typ einer Variable ändert, muss man auch das Kürzel anpassen, auch wenn die Bedeutung sich nicht ändert.

Interessant, daß sich alle anti-UN Argumente nur auf Systems Hungarian beziehen. Richtig angewendet, steht in der UN nicht der Typ der Variablen (das wäre in der Tat redundant), sondern ihre Aufgabe - z.B. ist 'aData' ein Array von Daten (ob das ein C-Array, ein dynamisch verwaltetes Array oder ein STL-Container ist, spielt keine Rolle).

asc

CStoll schrieb:

Interessant, daß sich alle anti-UN Argumente nur auf Systems Hungarian beziehen. Richtig angewendet, steht in der UN nicht der Typ der Variablen (das wäre in der Tat redundant), sondern ihre Aufgabe - z.B. ist 'aData' ein Array von Daten (ob das ein C-Array, ein dynamisch verwaltetes Array oder ein STL-Container ist, spielt keine Rolle).

Ich kenne auch nur die "Systems Hungarian" als ungarische Notation, davon abgesehen würde ich statt einen Kürzel lieber hinschreiben was der Sinn ist, so würde aus dem 'aData' bei mir ein 'DataList' werden - wobei ich das 'Data' auch noch hinterfragen würde, welche Daten konkret gemeint sind und es entsprechend anpassen wenn man sich auf etwas genaueres Festlegt. Ich finde es auf jeden Fall unabhängig vom Wissensstand leichter lesbar wenn ich statt einen aData ein DataList lese.

Ja, es ist mehr Schreibaufwand, aber ich erwarte von einem Guten Buch auch das man nicht mit Abkürzungen um sich schmeißt.

cu André

byto

Der Name eines Arrays oder einer Liste sollte Aufschluss darüber geben, was sich darin befindet. Ich würde sie also einfach userNames nennen, wenn sich darin Benutzernamen befinden. Anhand der Mehrzahl (s am Ende) weiss ich, dass es sich um mehrere Objekte handelt. Den genauen Typ verrät mir bei Bedarf die IDE, wenn es nicht eh schon aus dem Kontext hervorgeht.
Es gibt keinen Grund, irgendwelche Implementierungsdetails in die Namen zu kodieren. Schließlich ist es für gewöhnlich die fachliche Semantik, die die Komplexität ausmacht und nicht ob ich jetzt grade ein Array oder eine Liste vor mir habe.

groovemaster

CStoll schrieb:

Die Systems Hungarian (und das ist leider die verbreitete Variante) hatte noch nie wirklich Sinn - Apps Hungarian ist durchaus sinnvoll (egal wie gut die IDE wird).

Apps halte ich genauso für wenig sinnvoll. UN ist imo grundsätzlich nicht brauchbar, erst recht nicht in der heutigen Zeit mit besseren IDEs und moderneren Sprachkonzepten.

Ich halte für die Benennung von Variablen zwei Sachen für sinnvoll bzw. erforderlich.

Erstens, Variablen sollten _aussagekräftige_ Namen haben.

list<string> eine_liste;

ist ebenso wenig sinnvoll wie

string v;

Da ist

list<string> wochentage;
// bzw.
string vorname;

deutlich besser. Für Laufvariablen sind kurze Bezeichner (i, j) aber durchaus i.O.

Und zweitens, Variablen können durchaus ihrer Domain zugeordnet werden. Präfix m_ bzw Suffix _ für Membervariablen sind bekannte Beispiele dafür. Dies sollte aber nicht übertrieben werden, zumal es bei scopebasierten Sprachen auch nicht wirklich notwendig ist.

Was man definitiv _nicht_ machen soll, im Namen Typinformationen zu codieren. Auch keine Typklassifizierung (String, Integer, Array, Index, ...). Mal abgesehen von zusätzlichem Verwaltungsaufwand, Inkonsistenz, geringerer Lesbarkeit und Mehrdeutigkeit, ist sowas bei objekt- und konzeptorientierten Sprachen vollkommen kontraproduktiv.

EXDW

ich les immer von geringerer lesbarkeit - das ist doch bloedsinn - durch UN ist es nicht weniger lesbar als ohne, ich find es ist dadurch sogar noch besser lesbar

Helium

Langsam kann ich Trolle verstehen. Bei solchen Threads hat man einfach lust irgend einen Blödsinn zu schreiben.

Wir sollten alle in stackorientierten Sprachen programmieren. Dann gäbe es keine Variablennamen mehr.

Jester

Mr Evil schrieb:

ich les immer von geringerer lesbarkeit - das ist doch bloedsinn - durch UN ist es nicht weniger lesbar als ohne, ich find es ist dadurch sogar noch besser lesbar

aber klar doch paulWeights ist prima lesbar, handelt es sich doch nicht etwa um Pauls Gewichtsdaten, wie der unbedarfte Leser vielleicht annehmen könnte, sondern um einen "pointer to array of unsigned long" names Weights. Das steigert die Lesbarkeit natürlich enorm.

rüdiger

Mr Evil schrieb:

also wenn ich hier mal wieder {eigentlich taeglich} code durchlesen, und ich wuerde nicht gleich erkennen obs eine member ist - und was fuer ein typ usw, ich wuerde durchdrehen - muesste ich alles viel aufwendiger durchsehen

Dann scheinen die Probleme eher woanders zu liegen. Globale Variablen, zu lange Funktionen/Methoden oder printf-Style-APIs, wo man den Typ selbst wissen muss etc.

Normalerweise interessiert der konkrete Typ doch nicht.

EXDW

Jester schrieb:

aber klar doch paulWeights ist prima lesbar, handelt es sich doch nicht etwa um Pauls Gewichtsdaten, wie der unbedarfte Leser vielleicht annehmen könnte, sondern um einen "pointer to array of unsigned long" names Weights. Das steigert die Lesbarkeit natürlich enorm.

Das beispiel ist doch hirnrissig, wenn ein pointer zum array dann
paWeights
zudem handhaben wir das alles so der der bezeichner am anfang klein geschrieben wird, und der selbstname gross beginnt
pointer to array von weights waere wie gesagt
paWeights
und wenn es paulas gewicht ist
paPaulaWeights
es sind in diesem fall 2 zeichen mehr die direkt erkennen lassen was die variable ist - ich seh da kein problem

byto

Der Mehraufwand beim Refactoring würde mich aber ziemlich nerven. Und wenn mal jemand zu faul ist und den Namen bei Typänderung nicht ändert, ist das Chaos komplett. Darüber hinaus interessiert der Typ nicht, wenn man Code einfach nur bzgl. der Fachlichkeit "lesen" will.

CStoll

Wieso reiten hier immer noch alle auf dem "Typ" herum? Der Typ einer Variable steht in der Definition, den brauchst du nicht noch im Namen zu codieren - die eigentliche Funktion der UN war es, die Aufgabe der Variablen zu kennzeichnen.

Apollon

Was im Grunde genauso obsolet ist, weil der Name es andeutet.

tfa

Apollon schrieb:

Was im Grunde genauso obsolet ist, weil der Name es andeutet.

Genau. Die UN wird obsolet durch sinnvolle Namenswahl. So einfach ist das.