Sauberes Programmieren // Varibeln mit Prefix

[Styler]

Es ist eigentlich scheiß egal, hauptsache man hält sich konstant an einen Stil.

[junix]

Original erstellt von Shade Of Mine:
nun bist du voll vertieft im projekt und weisst jetzt nicht ob du iSumme oder uiSumme nehmen musst.

Deshalb sollte man konsequent die gleichen präfixe benutzen. Also unsigned int und int werden immer als ui bzw. i bezeichnet... Egal ob unterschieden wird oder nicht. (wobei ich mich sowieso frage wieso du unterschiedliche typen verwendest wenns ja eh nicht drauf an kommt?)

-junix

[Daniel E.]

Was ist denn nun passiert? Ich war 5 Tage im Urlaub und schon ist OOP out oder wie?

Ein Zeiger auf eine Basisklasse kann auf alle abgeleiteten zeigen. Damit ist das Konvept des statischen Typen, den ich in einen Variablenname packen kann dahin (Man könnte den Namen aus der vtable zurückgewinnen ... :)).

Original erstellt von junix:

• Wenn einer den Quelltext liest, muss er sich nicht immer fragen "was war das noch gleich für ein Typ?" und in den Deklarationen nachschauen.

Das muss er sowieso, wenn der Code so kaputt ist, dass man weder an dem Namen noch am Verwendungszweck (3 Zeilen davor und 3 Zeilen danach) erkennen kann. Alternativ könnte er den Quelltext neu schreiben.

Oben Genanntes gilt auch bei Fragen nach Überlauf oder ähnlichem, da man ja den bereich durch den Datentyp (z.B. int) gleich mitdokumentiert hat.

Überläufe sind lästige Low-Level-Probleme, die man nicht lokal sondern irgendwo zusammengefasst kontrollieren möchte (Signale und Exceptions).

Ändert ein Datentyp, ändert der Variablenname. das hat zur Folge, dass man die Namen anpassen muss. Kann ein nachteil sein, hat aber den Vorteil, dass man gleich überall - ohne etwas zu vergessen - überprüfen kann ob dann überhaupt noch gültig ist, was man da geschrieben hat.

Dafür hätte ich ehrlich gesagt Suchen&Ersetzten angewendet. Auf das ganze Projekt, vermutlich.

Prä-/Suffixe bieten eine gedankenstütze sowohl beim lesen als auch beim codieren.

Sie lenken vom Wesentlichen ab.

Ich hab hier lesen müssen dass es mit C++ egal sei, welchen typ man nehme vonwegen Templates und so.

Nein. Du musstest nichts lesen.

Und überhaupt prüfe der Compiler ob gültig sei was man schreibt.
Das ist fertiger Unfug!

Huch? Ein Compiler prüft nicht, was in ihn reingefüttert wird? Wie will er sonst Code erzeugen, wenn er den Quelltext nicht prüft?

Würde man obiges Argument bei Ada oder Pascal oder anderen streng typerisierten Sprachen anführen müsste ich recht geben.

Pascal ist nicht sehr streng getypt. Strenger als C, ja. Aber wenn sich verschiedene Integertypeninstanzen einander zuweisen lassen, so ist das nicht streng getypt. YMMV.

Der Compiler stört sich schon gar nicht dran.

Eine Warnung kann er dir sicher produzieren (Manchmal sind Warnungen sinnvoll).

[Marc++us]

So ganz läßt sich auch bei unter C++ der Nutzen einer Präfix-Notation nicht absprechen.

Nehmen wir als schönes abschreckendes Beispiel einen VCL-Dialog mit dem C++-Builder, wo 8 Checkboxen, 3 Listboxen und 8 Editfelder im Dialog stehen.

Wie nennen wir die Dinger nun?

Ich finde es dort sehr hilfreich, wenn man die Memberobjekte mit entsprechenden Kürzeln wie lb, edt, chkbx usw am Anfang kennzeichnet. Gerade weil Dialogklassen im Regelfall nicht sonderlich designed sind, und weil sie auch nie so gut verinnerlicht sind. Da komme ich nun her und will bei einem fremden Dialog bei einer bestimmten Auswahl noch eine Checkbox sperren. Da ist es deutlich hilfreich, wenn man am Namen auch den Typ des Dialogelements erkennt. Und das lb, edt, chkbx ist wohl durchaus UN.

Bei solchen Sachen hat man nämlich Abweichungen:
es gibt im Regelfall sehr viele Memberobjekte, mehr als in normalen Workerklassen
Dialogklassen sind als Hilfsklassen nicht so im Brennpunkt wie andere Dinge, so daß verschiedene Leute hingreifen und man sich nicht mehr so gut an Details erinnert

Mir ist diese 100%-Verinnerlichung von Guru-Regeln nicht ganz geheuer. Zum einen, weil die Gurus die Namensregeln alle paar Jahre ändern (man denke nur an die Wanderung des _ durch die Namen von Memberobjekten). Heute ziehen alle mit, Heerscharen von Freiwilligen codieren die OS-Quelltexte um damit sie den Guru-Regeln entsprechen, und 2004 kommen die Jungs mit einer neuen Regel, wie üblich mit Kommentaren, warum dies nun auf einmal viel besser ist. Und wieder gibt es zahllose Verfechter dieser neuen Regel, und alle Leute schreiben ihren Code um.

Ganz klar, die UN ist unter C++ tot, was man ja auch an aktuellen Code-Beispielen von MS sieht. Unter C hat es durchaus gute Gründe für solche Regeln. Aber irgendwo ziehen sich die Leute halt auch die Hose mit Beißzangen an:

Ein UNler würde schreiben:

CustomerData cdtaCurrentCustomerData;

und ein moderner C++-OOPler:

CustomerData currentCustomerData;

Wow. Da liegen natürlich Welten dazwischen... ich für meinen Teil erkenne aber auch bei den heute empfohlenen Namensgebungen für Objekte immer noch einen Algorithmus, dessen sich letztlich auch die UN bedient hat. Nur waren dort die Bezeichner kürzer.

[imho]

Es geht doch bei der UN nur um Basistypen. Bei eigenen Objekten ist es natürlich out.

[PeterTheMaster]

bei den dialogen stimme ich dir zu. da heissen die dinger bei mir auch gern
sliderH und sliderW oder editH und editW. und sind vom typ Slider oder Edit(box). da empfindet man das aber nicht wirklich also "variablentyp mit einbauen", sondern die objekte heissen ja auch umgangssprachlich so: man muss den hoehen-slider nehmen, um die hoehe zu veraendern. den aktuellen wert sieht man in der hoehen-editbox.
aber nicht (klassiche UN): ich addiere die beiden summand-zahlen um auf die summe-zahl zu kommen.

[ Dieser Beitrag wurde am 05.03.2003 um 14:10 Uhr von PeterTheMaster editiert. ]

[Walli]

Original erstellt von PeterTheMaster:
bei den dialogen stimme ich dir zu. da heissen die dinger bei mir auch gern
sliderH und sliderW oder editH und editW.

Ja, aber auch bei anderen Variablen ist es ganz hilfreich einen Präfix zu verwenden. Woher willst du z.B. nach 2 wochen noch wissen von welchem typ z.B. die Variable hausnummer in deinem Adressprogramm war? int, unsigned, short, char oder vielleicht sogar ein string? Man sollte IMHO zumindest kennzeichnen worum es sich handelt. Und sei es, dass man closeFlag schreibt anstatt bClose oder testStr anstatt strTest. Ich finde es bei Class-Members auch einfach schöner ein m_ davor zu setzen und das p vor dem Pointer halte ich für ziemlich sinnvoll...

[junix]

Original erstellt von Daniel E.:
Was ist denn nun passiert? Ich war 5 Tage im Urlaub und schon ist OOP out oder wie?

Was hat die Namensgebung mit OOP zu tun?

Original erstellt von Daniel E.:
Das muss er sowieso, wenn der Code so kaputt ist, dass man weder an dem Namen noch am Verwendungszweck (3 Zeilen davor und 3 Zeilen danach) erkennen kann

Den Verwendungszweck "Produkt aus zwei zahlen errechnen" verrät dir noch nichts über die Grössen der verwendeten Datentypen würd ich mal behaupten oder?

Original erstellt von Daniel E.:
Überläufe sind lästige Low-Level-Probleme, die man nicht lokal sondern irgendwo zusammengefasst kontrollieren möchte (Signale und Exceptions).

Und doch sind es die ach so lästigen low-level Probleme die einem am Meisten Ärger bereiten können. Klar möchte man die Überläufe zusammengefasst kontrollieren können nur gibt dir C(++) da keine Mittel für mit und remember: wir sprechen hier von C(++) und nicht von Ada, Eiffel oder so...

Original erstellt von Daniel E.:
Dafür hätte ich ehrlich gesagt Suchen&Ersetzten angewendet. Auf das ganze Projekt, vermutlich.

Hmmm wieso wunderst du dich dass OOP out sei, wenn dus gar nicht verwendest? Wenn du durch ein ganzes Projekt und nicht nur innerhalb einer Klasse einen Variablennamen ersetzen musst, dann hast du irgendwie nicht sehr objekt orientiert gearbeitet. D'accord?

Original erstellt von Daniel E.:
Sie lenken vom Wesentlichen ab.

Ich denke die Typerisierung ist doch sehr wichtig. Zumal zum beispiel bei der Fehlersuche nichts als korrekt angenommen werden sollte...

Original erstellt von Daniel E.:
Nein. Du musstest nichts lesen.

Wieso kommentierst du das was keines Kommentars bedarf? Wenn ich mich über die Meinungen hier informieren wollte musste ich das lesen.

Original erstellt von Daniel E.:
Huch? Ein Compiler prüft nicht, was in ihn reingefüttert wird? Wie will er sonst Code erzeugen, wenn er den Quelltext nicht prüft?

Er prüft die Typenkonversionen nicht. Er kann zwar - bei bedarf - Warnungen ausprinten, wenn man aber ein SDK mitcompilen muss kann es gut sein, dass dann einige tausend warnungen alleine aus dem Framework etc. daherkommen. Dann neigt man nur Naturgemäss shcon dazu diese Warnungen gar nicht mehr zu beachten.

Original erstellt von Daniel E.:
Pascal ist nicht sehr streng getypt. Strenger als C, ja. Aber wenn sich verschiedene Integertypeninstanzen einander zuweisen lassen, so ist das nicht streng getypt

Tschuldige, ich hab mich falsch ausgedrückt. Ada ist streng typerisiert. Pascal steht irgendwo dazwischen. Immerhin kannst du da nicht einfach einem BYTE einen Integerwert zuweisen. Das reicht doch schonmal?

Original erstellt von Daniel E.:
(Manchmal sind Warnungen sinnvoll).

Alle Warnungen sind sinnvoll solange sie sich auf den eigenen Source beziehen in dem man auch dafür sorgen kann dass sie verschwinden.

Original erstellt von Marc++us:
Mir ist diese 100%-Verinnerlichung von Guru-Regeln nicht ganz geheuer.

Kann ich nur zustimmen. Guru-Regeln sind - in meinen Augen - nur dazu gut, eine Richtung vorzugeben. Man sollte sich allerdings im Rahmen des vernünftigen und nicht sklavisch dran halten. Guru Regeln dienen meines Erachtens dazu, jemandem die "sichere Seite" zu zeigen, der sich nicht in der Lage fühlt, die Konsequenzen seines Handelns abzuschätzen.

Original erstellt von Marc++us:
Ein UNler würde schreiben:
CustomerData cdtaCurrentCustomerData

Ne, ich würde hier schreiben "CustomerData CurrentCustomer_CustData" oder so in der Art.

-junix

[DrGreenthumb]

Ich wüsste nicht wieso ich while( b_running ) statt while( running ) schreiben sollte. Running könnte auch ein int oder so sein. Das interessiert doch aber garnicht. Jedenfalls nicht beim Lesen. Und beim Schreiben sollte man schon wissen womit man da rumhantiert.

Ein pObjekt könnte bei mir schonmal vorkommen. Aber nur wenn es von Bedeutung ist, dass es sich um einen Zeiger handelt. Und das ist es meistens nicht.

Wenn man sich nicht gerade durch seitenlange Funktionen kämpfen muss, sieht man ohnehin auf einen Blick um welchen Typ es sich handelt.

Ne, ich würde hier schreiben "CustomerData CurrentCustomer_CustData" oder so in der Art.

Um Gottes Willen...

[ Dieser Beitrag wurde am 05.03.2003 um 15:17 Uhr von DrGreenthumb editiert. ]

[junix]

Original erstellt von DrGreenthumb:
Ein pObjekt könnte bei mir schonmal vorkommen. Aber nur wenn es von Bedeutung ist, dass es sich um einen Zeiger handelt. Und das ist es meistens nicht.

Um Gottes willen...

Das heisst also du schreibst nicht konsequent "pObjekt" sondern einfach nach belieben? Dann würd ich auch ganz auf Prä-/Suffixe verzichten. Wozu selber jedesmal drüber nachdenken ob ein "p" hier wohl angebracht wäre oder nicht? Und - noch schlimmer - dem Lesenden zumuten dass er deine Entscheidung nachvollziehen kann?

Ausserdem: Wieso interessiert dich das nicht was running denn genau ist? Wann liest du bitte den Quellcode? Dann wenn du
a) einen Source-Audit durchführst
b) einen Fehler suchst

In beiden Fällen ist der Typ von running ebenso interessant wie beim codieren.

-junix

[Marc++us]

Original erstellt von PeterTheMaster:
bei den dialogen stimme ich dir zu. da heissen die dinger bei mir auch gern
sliderH und sliderW oder editH und editW.

Du übersiehst aber die grundsätzliche Gefahr bei dieser Diskussion: hier schreiben Leute "verwendet niemals Präfixe, weil die Gurus das auch nicht machen und veraltet ist". Wir verbreiten hier fundamental wirkende Pauschalaussagen, obwohl es begründete Ausnahmen (die auf praktischen Erwägungen und Überlegungen beruhen) davon gibt.

Unterschätz mal nicht die Bedeutung die es hat, wenn hier eine solche Aussage als "das macht man immer so" steht...

[meistens]

gibt es sowieso jemand vor, wie man zu schreiben hat

[DrGreenthumb]

Original erstellt von junix:
Das heisst also du schreibst nicht konsequent "pObjekt" sondern einfach nach belieben?

hmm.. Ja.. Nein, nicht nach belieben. Wobei ich ehrlich gesagt nicht immer ganz konsequent bin, aber davon mal abgesehen.

Player* player = new Player();
Würde ich nie pPlayer nennen, weil player ohnehin immer ein Zeiger ist und überall auch so behandelt wird.

Player p1, p2;
Player* pPlayer = &player1;
Da sieht das anders aus. pPlayer ist halt nur ein Zeiger auf den eigentlichen Player.

Aber dieses Zeiger-Gedöns ist ein Spezialfall.Generell kennzeichne ich die Variablen nicht. Ich hatte bisher weder bei eigenem, noch bei Fremdcode das Bedürfnis dazu.

Und der Quelltext ist einfach hübscher

[HumeSikkins]

Hallo,
komisch. Ist Daniel E. hier der einzige der sowas wie "Definitionen so spät wie möglich", "Namen so lokal wie möglich" oder "kurze Funktionen" berücksichtigt?

Wenn ich in einem C++ Programm erst 700 Zeilen und drei Dateien früher feststellen kann, was ein Objekt für einen Typ hat, dann ist das für mich kein Zeichen dafür, dass mir die UN helfen würde sondern vielmehr dafür, dass der Code kaputt ist.

@Marc++us
Seit wann geht es denn generell um Präfixe? Ich dachte es geht um die UN. Und die ist im Zusammenhang mit C++ tot. Mehr habe ich auch nie gesagt.

[Walli]

Original erstellt von HumeSikkins:
Seit wann geht es denn generell um Präfixe? Ich dachte es geht um die UN. Und die ist im Zusammenhang mit C++ tot. Mehr habe ich auch nie gesagt.

Naja, das Thema lautet "Sauberes Programmieren // Variablen mit Prefix"... Da liegt es doch nahe nicht nur über UN sondern über den generellen Sinn/Unsinn von Präfixen zu reden...

[ts]

es ist immer dasselbe, wenn es um Code-Pseudo Richtlinien geht, dann entsteht eine brennende 10 Seiten Debatte, die nie zu einem Ende führt, weil sich die Parteien nicht überzeugen lassen werden!

[rüdiger]

Original erstellt von HumeSikkins:
**Hallo,
komisch. Ist Daniel E. hier der einzige der sowas wie "Definitionen so spät wie möglich", "Namen so lokal wie möglich" oder "kurze Funktionen" berücksichtigt?

Wenn ich in einem C++ Programm erst 700 Zeilen und drei Dateien früher feststellen kann, was ein Objekt für einen Typ hat, dann ist das für mich kein Zeichen dafür, dass mir die UN helfen würde sondern vielmehr dafür, dass der Code kaputt ist.**

Da muss ich euch recht geben, nicht umsonst darf man ja auch in C mittlerweile überall Variablen deklarieren, wo man will im Scope.

Aber was ich nicht verstehe, wenn jemand UN benutzt, mit der Argumentation, dass man es leichter lesen kann (was nach meiner Meinung eh nicht stimmt ...), dann sollte er doch auch seine Funktionen nach der UN beschriften (spätestens dann sollte euch auffallen, wie dumm so etwas ist, kleines Beispiel, wie man zB. die Funktion select(2) bennenen müsste "iselect_i_f_f_f_t", dass ist jetzt aber nicht wirklich lesbarer als select finde ich ;))

übrigens verstehe ich eh nicht, wie UN dafür sorgen soll, dass man Code besser lesen kann, da die Abkürzungen ja teilweise sehr merkwürdig sind und sich von Porjekt zu Projekt (und von Programmierer zu Programmierer) unterscheiden. Was bringt es, wenn ich jedesmal im Handbuch nach der abkürzung gucken muss?

[Walli]

Original erstellt von kingruedi:
**Aber was ich nicht verstehe, wenn jemand UN benutzt, mit der Argumentation, dass man es leichter lesen kann (was nach meiner Meinung eh nicht stimmt ...), dann sollte er doch auch seine Funktionen nach der UN beschriften (spätestens dann sollte euch auffallen, wie dumm so etwas ist, kleines Beispiel, wie man zB. die Funktion select(2) bennenen müsste "iselect_i_f_f_f_t", dass ist jetzt aber nicht wirklich lesbarer als select finde ich ;))
**

Bei Funktionen kenne ich keinen der UN verwendet (Warum auch, wichtige Funktionen sollte man sowieso kurz mal im Code kommentieren wenn Zeit ist). Es ist aber nun mal halt die Meinung von seeeehr vielen Leuten, dass eine gewisse Markierung von Variablen Sinn macht... Was ist da schlimm dran. Ich sehe die Nachteile nicht die ihr hier aufzählt. Ob ich bTest schreibe oder test oder testFlag ist doch im Prinzip egal, es sollte nur einheitlich im eigenen Code sein. Unleserlich wird es IMHO erst wenn man in der Notation herumwankt und mal dies mal das verwendet...

Original erstellt von kingruedi:
übrigens verstehe ich eh nicht, wie UN dafür sorgen soll, dass man Code besser lesen kann, da die Abkürzungen ja teilweise sehr merkwürdig sind und sich von Porjekt zu Projekt (und von Programmierer zu Programmierer) unterscheiden. Was bringt es, wenn ich jedesmal im Handbuch nach der abkürzung gucken muss?

Du brauchst doch wohl eher ein Handbuch wenn du keine Abkürzungen verwendest. Ausserdem, was soll bSonstwas oder nSonstwas denn sonst sein als ein bool bzw. eine Zahl...???

Meiner Meinung nach sollte in solchen Sachen niemand ein endgültiges Urteil fällen. Dem einen hilft's dem anderen nicht. Guter und schneller Code bleibt auch trotz Notation gut. Und das Urteil über die Lesbarkeit sollte ja wohl jeder selber fällen dürfen

[rüdiger]

Du brauchst doch wohl eher ein Handbuch wenn du keine Abkürzungen verwendest.

(ich geh mal davon aus, dass du mit Abkürzungen die UN meinst ;))

Ja, ein Handbuch um nachzuschlagen, was die Variable macht und nicht eines um erstmal nachzulesen, wie man die Variable überhaupt schreibt

[Walli]

Original erstellt von kingruedi:
**(ich geh mal davon aus, dass du mit Abkürzungen die UN meinst ;))
So ist es
**

Original erstellt von kingruedi:
Ja, ein Handbuch um nachzuschlagen, was die Variable macht und nicht eines um erstmal nachzulesen, wie man die Variable überhaupt schreibt

Wie gesagt, ich finde die richtige UN scheiße aber eine eigene Notation (die bei mir zumindest einige Gemeinsamkeiten mit der UN hat ) nicht so schlecht wenn man es nicht übertreibt. Eigentlich sollte man ja auch ein ch vor Character setzen und ein sz zeigt an, dass es sich um einen Pointer auf den ersten Character eines Strings handelt. So eng muss man es doch garnicht nehmen. Aber ein str vor einen String zu setzen und ein b vor ein bool ist sinnvoll.

Beispiel von Microsoft für Ungarische Notation:

1   #include "sy.h"
2   extern int *rgwDic;
3   extern int bsyMac;
4   struct SY *PsySz(char sz[])
6      {
7      char *pch;
8      int cch;
9      struct SY *psy, *PsyCreate();
10      int *pbsy;
11      int cwSz;
12      unsigned wHash=0;
13      pch=sz;
14      while (*pch!=0
15         wHash=(wHash<>11+*pch++;
16      cch=pch-sz;
17      pbsy=&rgbsyHash[(wHash&077777)%cwHash];
18      for (; *pbsy!=0; pbsy = &psy->bsyNext)
19         {
20         char *szSy;
21         szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
22         pch=sz;
23         while (*pch==*szSy++)
24            {
25            if (*pch++==0)
26               return (psy);
27            }
28         }
29      cwSz=0;
30      if (cch>=2)
31         cwSz=(cch-2/sizeof(int)+1;
32      *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
33      Zero((int *)psy,cwSY);
34      bltbyte(sz, psy->sz, cch+1);
35      return(psy);
36      }

Schrecklich, oder??? Ich denke die meisten hier reden von Präfixen und nicht von der UN, oder???