Sauberes Programmieren // Varibeln mit Prefix

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

[junix]

@Hume: hier gehts ja nicht nur um Variablen innerhalb eines Blocks sondern auch um Membervariablen, etc.?

@kingruedi: scherzkeks. Das ist genau das was zum Beispiel Marc++us sagen wollte (glaub ich zumindest) und was ich auch zu sagen versuchte (in meinen letzten oder vorletzten post):
Regeln sollten nicht sklavisch sondern mit Verstand eingehalten werden.

Original erstellt von Daniel E.:
[...Beschreibung des Basisklassendilemma...]

Eigentlich kein Problem. Der Zeiger an sich zeigt ganz klar auf ein Objekt das den Typen der Basisklasse besitzt (ob nun als letztes Element der Hierarchie oder ned sei dahin gestellt). Damit das Objekt dann tatsächlich nicht mehr z.B. auf CObject sondern auf CButton (oder so) zeigt, ist ein Cast erforderlich. Man kann also sagen, dass der Ergebniszeiger des Casts nicht mehr den Typen CObject sondern CButton hat.

Original erstellt von Daniel E.:
Keine genormten. Praktisch kann ich das.

Praktisch kann man alles... es ist nur eine Frage ob der Aufwand vertretbar ist oder nicht. Und das bischen mehr schreiben da sman da auf sich nimmt, das fällt sowieso kaum ins gewicht wenn man sich die "Lines of Code" pro Tag-Statistik ansieht.

Original erstellt von Daniel E.:
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.

Wie du bereits gesagt hast... dieses beispiel ist an den Haaren herbeigezogen und findet keinen Platz in der Praxis.

Original erstellt von Daniel E.:
Wie soll er sonst herausfinden, ob sie gültig war?

Benimm dich nicht schwierig (: Du weisst genau, dass ich damit meinte dass er nicht prüft ob ein long einem char zugewiesen wurde oder ned (: (ausser du stellst den Warnlevel hoch)

Original erstellt von Daniel E.:
[...pascal und Typensicherheit...]Für was?

Um damit typensicherer zu sein als C(++) und so viele Fehler schon mal auszuschliessen?

Original erstellt von Daniel E.:
Finde ich nicht: 'if (a = b) 9;' ist absolut legal und mein Compiler warnt.

Ein scheussliches Konstrukt. Ausserdem wollen vermutlich die wenigsten leute prüfen ob eine Zuweisung erfolgreich ausgeführt wurde. In den meisten Fällen ist das einfach nur ein typischer Fehler. (weshalb auch "possibly incorrect assignment" gewarnt wird.)

-junix

[Daniel E.]

Original erstellt von junix:
Der Zeiger an sich zeigt ganz klar auf ein Objekt das den Typen der Basisklasse besitzt

Das hier passende Buzzword ist Vererbung. Ich zB habe von meiner Mutter geerbt und trotzdem bin ich eine, von meiner Mutter unterscheidbare, Person.

es ist nur eine Frage ob der Aufwand vertretbar ist oder nicht.

Der Aufwand offfensichtlich nicht korrekte Programme auszuliefern ist nicht vertretbar.

Wie du bereits gesagt hast... dieses beispiel ist an den Haaren herbeigezogen und findet keinen Platz in der Praxis.

Nett, dass ich so etwas immer wieder zu portieren habe, weil eine Person mit Tunnelblick davon überzeugt war, man könnte sich darauf verlassen, dass ein int 32 Bit habe ...

Du weisst genau, dass ich damit meinte dass er nicht prüft ob ein long einem char zugewiesen wurde

Natürlich überprüft er das. Er überprüft nicht, ob der long-Wert zufällig nicht im char-Bereich darstellbar ist. Das darf der Programmierer gerne tun; er kann sogar viel mehr. Er kann zB _beweisen_, dass dieser Fall nicht eintritt (Compiler können das auch können).

Um damit typensicherer zu sein als C(++) und so viele Fehler schon mal auszuschliessen?

Also folgt aus typensicher automatisch, dass man viele Fehler ausschließt? Kaum. Fehler ausschließen tut der Programmierer indem er keine Fehler in seinen Quelltext schreibt. Das er nicht immer sagen kann, ob das ein Fehler ist oder nicht, ist eher minder interessant, weil sich Fehlerabwesenheit sowieso nicht beweisen lässt.

Ausserdem wollen vermutlich die wenigsten leute prüfen ob eine Zuweisung erfolgreich ausgeführt wurde.

Dieses Konstrukt prüft ob der Ausdruck 'a = b' einen Wert '!= false' zurückliefert. Für hinreichend normale Typen wird also schlicht getestet, ob 'b != 0'.

Wenn der Compiler mit einer Art Datenbank für sinnlose Anwendungsfälle ankommt und mir verbietet, was ich zu tun habe, halte ich das für Schrott. Ich kenne das Problem, das ich lösen will vermutlich besser als der Compiler.

[Shade Of Mine]

Original erstellt von MaSTaH:
Bei Funktionen kenne ich keinen der UN verwendet (Warum auch, wichtige Funktionen sollte man sowieso kurz mal im Code kommentieren wenn Zeit ist)

Bei Variablen ist UN nicht gut zu verwenden (Warum auch, wichtige Variablen sollte man sowieso kurz mal im Code kommentiere wenn Zeit ist)

Wenn ich funktionen nicht kennzeichnen muss, warum dann variablen?
was bringt es mir zu wissen dass ich zahl ein int ist wenn ich nicht weiss was Summe() zurück gibt?

ich kann ja in der doku nachsehen. Aber hey: das kann ich bei Variablen auch...
und Wenn eine Funktion Summe heisst, dann gibt sie eine Zahl zurück - ob das jetzt double ist oder int ist doch erstmal egal... der compiler warnt mich schon wenn ich nen double an nen int zuweise.

[ah! (Ausruf des Erstaunen]

hui, was haben wir da auch eine hübsche Funktion, hört sich der Name nicht toll an: accumulate (um im Standard zu bleiben)
Wie heißt nochmal der Header? algorithm, nicht?
na denn, probieren wir mal aus:
accumulate (a, b, c, d) wird mich der Compiler eh warenen, wenn da was falsch ist...
hm so in einer Zeile sieh das aber doof aus, da nehm ich doch lieber das d heraus und tu es davor
d = accumulate (a, b, c);

Ne Bitte Leute, wozu sind den Dokus da? Zum wegschauen? A!!! hilfe eine Doku!!! erdrück mich nicht!!!! Wenn ein Programmierer das nicht aushält, braucht er gar nicht erst zu programmieren. Und ich denke, das kann man auch auf weitere Lebensbereiche ausdehnen[1]
accumulate ist sogar ne Template Funktion, da

sind die Typen der Variablen eh egal

Haha.[2]
Ich bin ganz klar gegen die UN, aber auch nur, wenn Programmierer[3] endlich lernen in Dokus nachzuschlagen, und nicht auf ihr Halbwissen[4] vertrauen und Buggy Code schreiben.
Ich hab schon Seiten vorher mal gesagt, dass dieser Thread verschoben gehört. Und das sag ich jetzt nochmal, vielleicht gibt es ja jemanden, der seine Meinung langsam[5] ändert.

PS. accumulate befindet sich im Standard-Header numeric, erwartet 2 Vorwärtsiteratoren [anf,end), und einen int als 3. Argument (Startwert), und addiert zu diesem int alle Werte in [anf,end) und gibt die Summe zurück. Das Prädikat (+=) ist austauschbar

(1) Auf Deutsch: Es geht nicht nur Programmierern so.
(2) Ausdruck des Mitleids
(3) Achtung, Verallgemeinerung!
(4) Das soll keine Anspielung gegen HumeSikkins sein, eher das Gegenteil
(5) Nach 5 weiteren Seiten sinnloser Diskussion

[kartoffelsack]

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.

Und was ist, wenn da steht

while(running)
{
--running;
//...
}

Da isses dann schon interessant. Und mir jedesmal überlegen zu müssen, obs an der Stelle interessant is? Na, dann schreib ich lieber überall b_running. Und wenn da i_running steht und ich denk mir drei Wochen später, dass es da ein bool auch getan hätte, dann find ichs schon gut, wenn ich gezwungen bin jedes running einzeln zu ändern, weil ich mir dann den Code auf jeden fall nochmal angucke (sorry, ich mach nie sucher - ersetzen ohne mich an jeder Stelle einzeln fragen zu lassen.
Die Lesbarkeit wird durch die Präfixe auch nicht gestört. Kommt immer drauf an, was einen gerade interessiert - ich kann beim lesen die Präfixe durchaus gedanklich ausblenden. Und niemand hat gesagt, dass die Variablen hinter den Präfixen keinen aussagekräfigen Namen haben sollten.

Hab ganz weit vorne geschrieben, ich mach itrp für iterator auf Pointer. Da wurd ich dann gefragt, woher man weiß, dass es keine Pointer auf nen Iterator ist. Ganz einfach: ich würde dann pitr schreiben. Und wenn ich itrpPersonen tippe, hab ich 4 Buchstaben lang Zeit, dass mir einfällt, dass itrpPersonen->SetName() keinen Sinn macht.

Das Argument, dass man nich für jede Klasse ein Präfix erfinden kann zieht nicht, weils hier noch keiner verlangt hat. Interessant sind sie v.a. bei eingebauten Typen, Zeigern etc. Ich mach aber für manche Klassen ne Ausnahme: veciNumbers ist ein std::vector<int> und stiNumbers ist ein set<int>. Jetzt werden manche sagen, das das totaler Quatsch sei, weil man dann die Container nicht mehr einfach austauschen kann etc. Aber für mich ist ein vector mit Nummern etwas vollig anderes als ein set, weil das eine sortiert, das andere nicht sortiert ist (und auch die meisten Member-Methoden sind anders).

std::sort(Numbers);

Geht nicht? hm. Bei
std::sort(stiNumbers);
seh ich aber sofort, warum.

Anderes Beispiel:

Hausnummer

Frage? Was für ein Typ ist das? Ein int? ha, es gibt auch Hausnummern wie 3a oder so. Es ist ein fundamentaler Unterschied ob die Hausnummer ein string oder ein int ist - und beides mag je nach Anwendung sinnvoll sein und mit einem kurzen Blick in den Code nicht einfach festzustellen.

Ratschläge wie "wenn die Funktion kurz ist, siehts Dus doch sowieso sofort" sind völlig an der Realität vorbei imho. Ja, schön, ich mach kurze Funktionen. Aber meine Member-Variablen sind nunmal an ner ganz anderen Stelle definiert.

Machs wie in Java, zählt nicht. In Java gibts keine Zeiger es ist sowieso alles ne Klasse. Mein CKlasse mag vielen sinnlos erscheinen. Aber ich schreib nunmal lieber CKartoffelsack Kartoffelsack statt Kartoffelsack kartoffelsack. Wie viele Gurus haben schon gesagt, dass es blöd wäre, wenn ein Bezeichner groß geschrieben was anderes ist, als der gleiche klein geschrieben.

Übrigens find ich das Argument, man sollte die Typinfo hinten, nicht vorne machen wegen der Sortierung bei einer Autovervollständigung eigentlich ganz gut.

Aber im Grunde ist das alles Geschmacksache und kein Mensch verlangt, sich exakt an die UN von MS zu halten (die hat sich bestimmt auch mal geändert). Aber eigene - d.h. wenigstens Projektweite, noch toller aber firmenweite - durchgängige Notation sollte man haben. Und sich dabei an die UN anzulehnen mag manchen als kein Vorteil erscheinen, aber ein schlagkräftiges Argument, was dagegen spricht, hab ich noch nicht gelesen. Außer der Tipparbeit, aber das is irgendwie lächerlich. Zumindest so lang man sich bei

for_each(vector<map<std::string*, sort_predicate> >::iterator itrRun(Namen.begin()),
         vector<map<std::string*, sort_predicate> >::iterator itrRun(Namen.end()), 
machIrgendwas);

nen Wolf tippt (ohne UN und Präfixe).

[Walli]

Original erstellt von <pfui teufel>:
Mastah, woher hast du den Code?

Von hier

[Daniel E.]

Original erstellt von kartoffelsack:
**Und was ist, wenn da steht

while(running)
{
--running;
//...
}

Da isses dann schon interessant.**

Keineswegs. Wenn irgend ein Verrückter hier 'running' als 'bool' definiert hat, so hat er einiges fundamental falsch verstanden, in erster Linie mal die Schleifen (also etwas potentiell mehrfach [!=potentiell 1x] auszuführen).

Und wenn da i_running steht und ich denk mir drei Wochen später, dass es da ein bool auch getan hätte, dann find ichs schon gut, wenn ich gezwungen bin jedes running einzeln zu ändern, weil ich mir dann den Code auf jeden fall nochmal angucke

Die Abwesenheit eines 'i_' hindert dich daran, Quelltext zu lesen? Interessant.

Kommt immer drauf an, was einen gerade interessiert - ich kann beim lesen die Präfixe durchaus gedanklich ausblenden.

Man schreibt also etwas hin, um es gedanklich auszublenden? Tricky.

Und niemand hat gesagt, dass die Variablen hinter den Präfixen keinen aussagekräfigen Namen haben sollten.

Stimmt. Muss man das so machen?

std::sort(Numbers);

Geht nicht? hm. Bei
std::sort(stiNumbers);
seh ich aber sofort, warum.

Der Compiler sieht das auch. Und der glaubt dem Namen nicht.

Hausnummer

Frage? Was für ein Typ ist das? Ein int? ha, es gibt auch Hausnummern wie 3a oder so.

Das trifft sich gut, weil 0x3a ist ein int :).

Es ist ein fundamentaler Unterschied ob die Hausnummer ein string oder ein int ist - und beides mag je nach Anwendung sinnvoll sein und mit einem kurzen Blick in den Code nicht einfach festzustellen.

Es ist kein großer Unterschied. Es ist praktisch sogar absolut uninteressant, denn ich möchte ja bekanntermaßen auf Hausnummern operieren, nicht auf ints, nicht auf Strings.

Abstrakt. Man beschreibt im Computer meistens etwas abstrakt. So auch hier. Ich kann Hausnummern vergleichen, zusammenzählen, ausgeben, ohne dass ich wissen muss, ob Hausnummern intern Integer, Strings oder blaue Schildchen sind.

Aber meine Member-Variablen sind nunmal an ner ganz anderen Stelle definiert.

Ja, man muss lesen. Das ist immer so. Bei jedem Funktionsaufruf muss man die Argumente raussuchen (wie oben schon ausfürlich erklärt wurde).

In Java gibts keine Zeiger

Zeiger sind ein Konzept, die zB zum Laufen über Felder geeignet sind. Ob man sie Iterator oder Zeiger nennt ist absolut irrelevant. Darum ist auch dein Beispiel mit der itrp-Notation nicht treffend.

Übrigens find ich das Argument, man sollte die Typinfo hinten, nicht vorne machen wegen der Sortierung bei einer Autovervollständigung eigentlich ganz gut.

Dann hätte man es doch gleich weglassen können.

Und sich dabei an die UN anzulehnen mag manchen als kein Vorteil erscheinen, aber ein schlagkräftiges Argument, was dagegen spricht, hab ich noch nicht gelesen.

?
Es wurde gesagt, dass
a) es dem Gedanken der Objektorientierung zuwieder läuft
b) hiermit Konzepte (Name und Typ) vermengt werden, was doch ein erster Schritt zur Abstraktion wäre
c) keine Zusatzinformationen vermittelt werden
d) Kommunikation über den Quelltext unmöglich gemacht wird
e) es Mehraufwand für Leser und Programmier ist
f) zT falsche 'Informationen' geliefert werden
g) es zum Schlampen anregt
h) es Compiler gibt

Dagegen wurde gesagt, dass
a) man ohne Notation keinen Quelltext lesen könne
b) kein Zusatzaufwand ist (Begründung fehlt)
c) der Typ extrem wichtig ist
e) man keine Dokumentation lesen sollte

Der interessierte Leser möge sich die Argumentationen auf der Zunge zergehen lassen.

[Walli]

Original erstellt von Shade Of Mine:
**Bei Variablen ist UN nicht gut zu verwenden (Warum auch, wichtige Variablen sollte man sowieso kurz mal im Code kommentiere wenn Zeit ist)

Wenn ich funktionen nicht kennzeichnen muss, warum dann variablen?
was bringt es mir zu wissen dass ich zahl ein int ist wenn ich nicht weiss was Summe() zurück gibt?

ich kann ja in der doku nachsehen. Aber hey: das kann ich bei Variablen auch...
und Wenn eine Funktion Summe heisst, dann gibt sie eine Zahl zurück - ob das jetzt double ist oder int ist doch erstmal egal... der compiler warnt mich schon wenn ich nen double an nen int zuweise.**

Der einfache Grund dafür, warum ich es bei Variablen mache und bei Funktionen nicht: Bei Variablen finde ich es übersichtlicher (da kann man jetzt eigener Meinung sein oder nicht). Bei Funktionen sieht es einfach nur Schei$$e aus und versaut eher die Übersicht, da man diese auch dokumentieren kann. Aber: Wer dokumentiert den bitte jede Variable??? Also ich weiß durch die Präfixe und den Namen immer was gemeint ist. Ich finde es einfach nur schade, dass hier einige wenige Leute meinen ihr Style sei der einzig wahre und es gibt nix besseres. Wenn jemand 50 gotos in 60 Zeilen code hat dann lohnt sich solch eine lange Diskussion, aber bitte: Wir diskutieren hier seit 6 Seiten und 3 Tagen über die Benennung von variablen...

[Shade Of Mine]

Original erstellt von kartoffelsack:
Na, dann schreib ich lieber überall b_running. Und wenn da i_running steht und ich denk mir drei Wochen später, dass es da ein bool auch getan hätte, dann find ichs schon gut, wenn ich gezwungen bin jedes running einzeln zu ändern, weil ich mir dann den Code auf jeden fall nochmal angucke (sorry, ich mach nie sucher - ersetzen ohne mich an jeder Stelle einzeln fragen zu lassen.

schon mal probiert so 6000-10000 zeilen durchzugehen?
wer zahlt dir diese arbeitszeit?

also mein chef würd mich blöd anschauen wenn ich ihm sage: ich hab ne halbe stunde lange variablen umbenannt.

und wenn das ganze häufiger vorkommt na dann gute nacht.

[Shade Of Mine]

Original erstellt von MaSTaH:
Der einfache Grund dafür, warum ich es bei Variablen mache und bei Funktionen nicht: Bei Variablen finde ich es übersichtlicher (da kann man jetzt eigener Meinung sein oder nicht). Bei Funktionen sieht es einfach nur Schei$$e aus und versaut eher die Übersicht, da man diese auch dokumentieren kann. Aber: Wer dokumentiert den bitte jede Variable???

jede variable die sich nicht selbs dokumentiert wird kurz beschrieben.
genauso bei funktionen.

verstehst du das dilemma?
variablen werden anders behandelt als funktionen. das macht doch keinen sinn.

warum ist es OK für ne funktion in der doku nachzuschlagen, aber für ne variable ist n bisschen scrollen zuviel?