Sauberes Programmieren // Varibeln mit Prefix

[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???

[pfui deibel]

hanswurscht-code! da kommt mir das hühnchen wieder hoch!

[Daniel E.]

Original erstellt von MaSTaH:
Schrecklich, oder???

Ja.

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

Von Präfixen, die den Typ einer Variable beschreiben sollen. Das ist Unsinn, wie man hier mehrfach lesen 'musste'.
Andere Präfixe sind teilweise sinnvoll um bestimmte Dinge zusammenzufassen (Namespaces sind nicht das am weitesten verbreitete C++-Feature ...). Und dass man sich für mehrere Ausgabeelemente ähnlich benennt (also ein Namensschema einführt) ist auch klar.

Original erstellt von junix:
Was hat die Namensgebung mit OOP zu tun?

Wir haben einen Zeiger auf eine Basisklasse, also nach deiner Notation etwas, das auf *_p passt. Nun zeigt dieser Zeiger aber idR nicht auf die Basisklasse, sondern auf Abgeleitete. Diese abgeleiteten Klassen haben einen anderen Namen als die Basisklasse. Also kann ich keine Aussagen über das gezeigte Objekt, welche ich in den Namen quätschen könnte.

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?

Richtig. Es verrät, dass hier jemand zwei Zahlen miteinander multipliziert. Mehr steckt nicht drinn.

Klar möchte man die Überläufe zusammengefasst kontrollieren können nur gibt dir C(++) da keine Mittel für

Keine genormten. Praktisch kann ich das. Die Frage ist nur, ob jede Eingabe in ein Programm sinnvoll ist und wann das Programm lieber terminieren sollte.

Hmmm wieso wunderst du dich dass OOP out sei, wenn dus gar nicht verwendest?

Mich persönlich würde das nicht wundern, wenn OOP out wäre :).

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.

Vermutlich. Aber nehmen wir mal an (Achtung, unrealistisch), ich hätte an verschiedenen Stellen im Programm int verwendet und möchte zentral auf long umstellen.

Ich programmiere tatsächlich nicht OOig. Meine Programme sehen funktional aus, sagt man mir ...

Zumal zum beispiel bei der Fehlersuche nichts als korrekt angenommen werden sollte...

Eben! Auch keine Präfixe. Auch keine Variablennamen.
[Mancher würde nun das Programm nun formal und maschinell verifiztieren ...]

Wieso kommentierst du das was keines Kommentars bedarf?

Wieso kommentierst du das, was keines Kommentars bedarf?

Er prüft die Typenkonversionen nicht.

Wie soll er sonst herausfinden, ob sie gültig war?

[Pascal und Typensicherheit] Das reicht doch schonmal?

Für was?

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

Finde ich nicht: 'if (a = b) 9;' ist absolut legal und mein Compiler warnt. Es gibt auch welche, die warnen, weil sie Funktionen nicht inlinen wollen ...

[pfui teufel]

Mastah, woher hast du den Code?

[ich]

ich hab's schon immer gewusst, Daniel E. programmiert nicht objektorientiertig (OOig)

[Bashar]

erzähl was neues ...

[Nitromaus]

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 }

dass der code so scheiße aussieht liegt daran dass viel zu kurze nichst sagende namen verwendet werden.

wenn jetzt aber statt pb lieber pBlabla dastehen würde oder ähnlcihes dann würde des schon klarer sein.

Ich will nicht wissen was die Vorteile von der Un sind sondern eher die Nachteile ausser Schreibarbeit.

Ich habs sie früher nie genutzt nun schon und ich habe nur gute Erfahrungen mit ihr.