Ungarische Notation - Ein großes Missverständniss

unfan schrieb:

Was für eine Konvention verwenden Sie denn?

Im Forum halte ich mich an die Konvention, die Leute mit 'du' anzusprechen
Ansonsten muss ich sowas nehmen, was in deinem Artikel als "Sys Hungarian"
beschrieben wird. Finde ich mittlerweile aber auch ganz okay.

Jockel

Ponto

Der Artikel identifiziert das Problem, kommt aber meiner Meinung nach zur falschen Lösung. Sich an Namen aufzuhängen ist einfach zu fehleranfällig und sollte dem Compiler überlassen werden.

Warum nicht direkt zwei Typen benutzen:

SecureString
String

Und dann die Operatoren so einrichten:

String blabla = "Evil hacker code";
SecureString blub = "Teletubbie land";

blabla = blub;   // Funktioniert einwandfrei
blub = blabla;   // Compilererror
blub = convert_to_secure_string(blabla); // kein Problem

Man muss sich genauso wie bei der ungarischen Notation daran halten das zu benutzen. Aber sobald man die Eingabe des Users in einem String gespeichert hat, wird einen der Compiler solange in den Arsch treten, solange es noch irgendwo falsch benutzt wird. So ähnlich macht er das ja auch bei const.

unfan

Jockelx schrieb:

Im Forum halte ich mich an die Konvention, die Leute mit 'du' anzusprechen ;-)Jockel

Sorry, das "Sie" ist Berufsbedingt und sitzt mir mittlerweile irgendwie im Blut.

rüdiger

Hat eigentlich einer von euch den joelonsoftware Artikel gelesen? Da geht es doch darum, was die ungarische Notation wirklich bedeutet.

Es geht darum, dass man nicht den Typ auszeichnet, sondern die Funktion der Variable. Zum Beispiel colFoo, damit man weiß, dass Foo ein Column ist. So kann man colFoo von rowBar unterscheiden und sieht eben, dass es ein Fehler ist, wenn man einem column eine row zuweist.

Naja, man kann eben darüber streiten, ob es aus OO Sicht nicht eh verschiedene Typen für Column und Row geben sollte

Jester

kingruedi schrieb:

Hat eigentlich einer von euch den joelonsoftware Artikel gelesen?

Da du scheinbar der einzige bist kannst Du vielleicht auch gleich noch erklären, warum wir alle das Thema verfehlen wenn wir sagen, daß der Compiler das besser kann.

Ponto

unfan schrieb:

Ich achte ebenfalls strengstens auf Compiler-Warnings. In unserer Firma sind alle Sourcen zu 100% Warning-frei.

Das kann doch nur bedeuten, dass ihr nicht alle Warnungen eingeschaltet habt.
Beim gcc muss man nur -Weffc++ und -Winline angeben, dann hat meiner Meinung nach jeder nichttriviale Code Warnungen, die man nicht beheben will.

KlausB

Hallo

Ich achte ebenfalls strengstens auf Compiler-Warnings. In unserer Firma sind alle Sourcen zu 100% Warning-frei.

Dann ist SICHER die Warnstufe nicht auf alle gestellt ,
denn sonst haettet ihr 100erte Warnings (sicher)

Es sei denn ihr verzichtet auf alles (zB VCL....)
und schreibt reinen API-Code (selbst dann ist es eher unwarscheinlich)

MfG
Klaus

unfan

Das mit den 100% Warning-freien sourcen liegt ganz einfach daran das wir mittlerweile nicht mehr in C/C++ entwickeln. bzw.

unfan

kingruedi schrieb:

Naja, man kann eben darüber streiten, ob es aus OO Sicht nicht eh verschiedene Typen für Column und Row geben sollte

Da hast Du natürlich grundsätzlich recht. Ich bin jedenfalls ein großer Fan der "wirklichen" ungarischen Notation. Liegt wohl daran das ich schon häufiger in der Situation gewesen bin fremden Code bearbeiten zu müssen der entweder
a) in einer nicht-OO-Sprache implementiert war
oder
b) die OO-Merkmale der verwendeten Sprache eben nicht ausgenutzt hat.

In meinen Augen ist folgender (pseudo-) Code einfach herrlich übersichtlich:

// prefix "s" = safe string; "us" = unsafe string

us = UsRequest("name");
usName = us;
recordset("usName") = usName;
sName = SFromUs(recordset("usName");
WriteS(sName);

Wennn da irgendwo ein

sName = usName;

vorkommt, ist (mir) auf den 1.Blick klar, das es sich um einen Bug handeln muss.

Für mich ist jedenfalls ein Methodenaufruf wie

foo = FooFromBar(bar);

"leserlicher" als

foo = Convert_Bar_To_Foo(bar)

Mir ist schon auch klar das es andere Konventionen gibt, die vielleicht sogar besser sind. Das wichtigste ist jedenfalls dass es eine Konvention gibt, und man sich auch daran hält. Es gibt in kaum schlimmeres als Code der gemischte Konventionen bzw. gar keine verwendet. Sich in sowas reinzuarbeiten ist sehr, sehr mühsam.

Ponto

unfan schrieb:

Für mich ist jedenfalls ein Methodenaufruf wie
foo = FooFromBar(bar);
"leserlicher" als
foo = Convert_Bar_To_Foo(bar)

Das war ja auch nur ein Beispiel, um eindeutig zu sagen, was die Funktion macht. Wie man die im Endeffekt nennt, ist jedem selbst überlassen. FooFromBar ist auf jeden Fall eine sehr gute Alternative.

rüdiger

Jester schrieb:

kingruedi schrieb:

Hat eigentlich einer von euch den joelonsoftware Artikel gelesen?

Da du scheinbar der einzige bist kannst Du vielleicht auch gleich noch erklären, warum wir alle das Thema verfehlen wenn wir sagen, daß der Compiler das besser kann.

Weil

int colFoo=getCol();
int rowBar=getRow();
//...
rowBar=colFoo;

für den Compiler kein Problem ist, was aber sicher ein logischer Fehler ist. Lies dir einfach mal den joel Artikel durch.

Walli

doppelt: s.u.

Walli

KlausB schrieb:

Hallo

Ich achte ebenfalls strengstens auf Compiler-Warnings. In unserer Firma sind alle Sourcen zu 100% Warning-frei.

Dann ist SICHER die Warnstufe nicht auf alle gestellt ,
denn sonst haettet ihr 100erte Warnings (sicher)

Es sei denn ihr verzichtet auf alles (zB VCL....)
und schreibt reinen API-Code (selbst dann ist es eher unwarscheinlich)

Ach? Naja, ich schaffe es bei meinem aktuellen Projekt auf der Arbeit trotzdem auf Stufe 4 und Kompatibilitätswarnungen sauber durchzukompilieren. Und das, obwohl ich die (scheiß verbuggten) MFC einsetze...

kingruedi: Darüber, dass man Variablen sinnvoll benennen sollte streiten wir hier aber nicht, oder?

Jester

kingruedi schrieb:

für den Compiler kein Problem ist, was aber sicher ein logischer Fehler ist. Lies dir einfach mal den joel Artikel durch.

Schalt Dein Hirn an und lies was wir hier schreiben und: Trau uns zu, daß wir auch ein bißchen Ahnung haben.

Mit verschiedenen Typen meckert hier der Compiler und ich muß nicht hoffen, daß ich's beim Draufschaun zufällig sehe.
Siehe zum Beispiel den Link den ich weiter oben gepostet habe. (Aber den haste garnicht angeschaut weil ich ja den Artikel nicht gelesen hab, was?)