Sauberes Programmieren // Varibeln mit Prefix

1ntrud0r

(20 || 30) != 1mio

Shade Of Mine

Original erstellt von 1ntrud0r:
(20 || 30) != 1mio

geh in die müllkippe spielen (oder diskutiere)

1ntrud0r

Original erstellt von Shade Of Mine:
geh in die müllkippe spielen (oder diskutiere)

als mod würd ich mich mit so ner primitiven art mich zu artikulieren einbuddeln
sincerly

Edit : So nen Scheiss erwartet man normalerweise im Troll Forum aber nicht in nem richtigen ernsthaften Forum ... !

Ich hab den ... gefragt was zur Hölle er programmiert weil er von Millionen Prefixen redet du kommst mit 20 oder 30 daher und sabbelst was dahin wos nicht erwünscht ist , weder passt noch gefragt war ... so long .. wenn einer nen Recht hat sich zu beschweren bin das ich und nicht du @ shade of mine und wenn du meinst du müßtest pragmatisieren was du für nen kindskopf bist geh ins Troll Forum !

[ Dieser Beitrag wurde am 05.03.2003 um 09:31 Uhr von 1ntrud0r editiert. ]

virtuell Realisticer

Jetzt kommt mal wieder auf den Boden zurueck und hoert auf euch gegenseitig
fertig zu machen.

Deine Antwort habe ich so verstanden:

"Was zur Hoelle programmierst du, dass du millionen von Prefixen benoetigst?"

Shade hat es wahrscheinlich auch so verstanden und daraufhin geantwortet, dass
ein Projekt ohne weiteres 20 bis 30 Klassen haben kann (und das ist noch sehr
wenig).

Ich habe es so verstanden, dass er lediglich betont, wie unuebersichtlich es
wird, fuer jede Instanz einen Prefix zu bestimmen.

Wie schon gesagt gibt es in dem Projekt in dem ich Arbeite weit ueber 150 Klassen
und ich muesste mir mehr gedanken darueber machen, wie ich die Prefixe gestallte,
als dass ich produktiv an dem Projekt arbeiten koennte.

Ich bin sicher, dass er dich nicht dumm von der Seite anmachen wollte und mal
ehrlich, manchmal uebertreibt man ein wenig, um zu verdeutlichen wo die
Problematik liegt.

mfg
v R

[ Dieser Beitrag wurde am 05.03.2003 um 09:56 Uhr von virtuell Realisticer editiert. ]

Shade Of Mine

Original erstellt von 1ntrud0r:
als mod würd ich mich mit so ner primitiven art mich zu artikulieren einbuddeln
sincerly

schonmal davon gehört, dass man
1mio sagt, wenn man sehr viel meint?
scheinbar nicht.

Edit : So nen Scheiss erwartet man normalerweise im Troll Forum aber nicht in nem richtigen ernsthaften Forum ... !

Ich hab den ... gefragt was zur Hölle er programmiert weil er von Millionen Prefixen redet du kommst mit 20 oder 30 daher und sabbelst was dahin wos nicht erwünscht ist , weder passt noch gefragt war ...

ich dachte immer, wenn man in einem forum fragt und liest dann will man lernen.
scheinbar nicht.

so long .. wenn einer nen Recht hat sich zu beschweren bin das ich und nicht du @ shade of mine und wenn du meinst du müßtest pragmatisieren was du für nen kindskopf bist geh ins Troll Forum !

werde bloss nicht beleidigend.

wenn du schonmal professionelle anwendungen erstellt hättest, dann wüsstest du dass 20-30 Klassen relativ schnell erreicht sind. ich habe das als mindestzahl genannt, sonst kommt wieder einer und meinst: 200 Klassen sind ja viel zu viel.

wenn dir 30 prefixe nicht reichen, dann mach n großes projekt, da hast du dann 200-300 klassen oder mehr. schau dir mal an was die VCL oder MFC für klassen haben. jetzt addiere dazu noch mindestens 2 ne schöne libs noch dazu. dann addiere dein projekt mit seinen 30 klassen (weils n kleines ist) und du hast schon locker 500 klassen.

an eine million wirst du wohl schwer rankommen, aber: du machst ja nicht nur 1 projekt, sondern viele. und jetzt machst du halt 1 projekt in 2 monaten, das macht 6 projekte im jahr. das sind schon mal 3000 klassen. das machst du jetzt 20 jahre und du hast bereicht 60000 klassen.

es tut mir leid für dich dass du dich so angegriffen fühlst, aber lies dir deinen beitrag nochmal durch. du meinst das 30 ungleich 1mio ist.
soll man das ersnt nehmen? soll ich mir ver*****t vorkommen?
was willst du damit bezwecken?
eine diskussion führen definitiv nicht - es war vielleicht keine provokation, aber eine sinnvolle beteiligung an einer diskussion war es jedenfalls nicht.

wenn dich meine meinung nicht interessiert, dann ignoriere mich einfach, aber provoziere mich bitte nicht. ich bin bei so trollereien in fachforen leicht reizbar.

1ntrud0r

thx @ virtuell Realisticer wenigstens einer der nicht gleich auf 180 geht und sachlich bleibt für ne Klasse nen Prefix zu erfinden ist ja auch sehr unsinnig .. die Namen der einzelnen Klasse sollte ja schon genug sagen denke ich ..

Was ich jedoch beführworten würde ist die verwendung von prefixen bei .. variablen so rein der übersichtshalber ... wenn ich so die quake 2 engine anschau krieg ich nen magengeschwür ala : int a,b,c,d,e,f,g;

[ Dieser Beitrag wurde am 05.03.2003 um 10:15 Uhr von 1ntrud0r editiert. ]

crass

Und durch int ia,ib,ic,id,ie,if,ig wärs übersichtlicher?

dEUs

Nein, aber da ist das Problem ja uach nicht der fehlende Präfix, sondern die fehlende Benennung. Ich denke, die kann niemand so einfach wegdiskutieren
Ich persönlich bin ein Anhänger der UN, verwende sie aber nur bei eingebauten Typen, also nciht durchgehend und ich bin mit der Lesbarkeit meines Codes sehr zufrieden, mag es in anderen sourcen auch nciht, wenn man immer erst gucken muss, welchen typ die variable hat. Der Präfix soll ja keine exakte aussage machen. Präfix str nehm ich zb bei char*, TCHAR*, XYZCHAR*, CString, std::string ... Es ist also unmöglich, genau zu wissen, welcher Typ das jetzt ist, aber es gibt demjenigen, der den Code überfliegt, wenigstens nen Anhaltspunkt. Ich denke, dass das eher der Zwekc der UN ist und nciht, dass man den Typ EINDEUTIG identifizieren kann ...

crass

Ich finde Prefixe eigentlich nur bei zeigern ganz nützlich..vor jedem Zeiger ein p zB. Wenn man objektorientiert programmiert, sind pro Klasse die internen Variablen in der Regel eh sehr gut übershcubar, so daß man sich die häßlichen kryptischen Auswückse da vorne sparen kann..und WinApi ist imo für große Projekte unbrauchbar..man kommt nicht vorbei das in Klassen zu kapseln.

[ Dieser Beitrag wurde am 05.03.2003 um 10:34 Uhr von crass editiert. ]

Daniel E.

Original erstellt von dEUs:
Der Präfix soll ja keine exakte aussage machen. Präfix str nehm ich zb bei char, TCHAR, XYZCHAR*, CString, std::string ... Es ist also unmöglich, genau zu wissen, welcher Typ das jetzt ist, aber es gibt demjenigen, der den Code überfliegt, wenigstens nen Anhaltspunkt.**

Demzufolge: 'Derjenige, der den Code überfliegt'[1] wird mit einem

strName += iOtherName;

_nichts_ anfangen können.

Nehmen wir an, strName sei ein char* und iOtherName sei ein int. Ich möchte also die ersten iOtherName Zeichen über-/zurückspringen.
Nehmen wir an, iOtherName sei ein int und strName sei eine Instanz einer Stringklasse, die den 'Verkettungsoperator +=' auch für ints überlädt, weil das im Programm häufig gebraucht wird.
Nehmen wir an, iOtherName sei eine Instanz einer Klasse, die mit 'beliebig langen' natürlichen Zahlen rechnet; sie enthält einen Umwandlungsoperator für den Typen von strName, zB einen std::string.
uswusf.

_Das_ hilft niemanden.

[1]: Wieso sollte jemand Code überfliegen wollen. Auf jeden Fall nicht um ihn zu verstehen, denn dann würde er ihn lesen.

PeterTheMaster

intruder:
für ne Klasse nen Prefix zu erfinden ist ja auch sehr unsinnig .. die Namen der einzelnen Klasse sollte ja schon genug sagen denke ich ..
Was ich jedoch beführworten würde ist die verwendung von prefixen bei .. variablen

du provozierst doch absichtlich, oder? du wirst doch nicht ernsthaft glauben, dass hier jemand vorgeschlagen hat, vor einen klassennamen ein praefix zu tun. bei der UN geht es darum, den objektnamen einen praefix zu geben, um den typ zu erahnen. klassen sind typen.
"fuer ne klasse nen prefix zu erfinden" heisst also, den praefix den namen der instanzen der klasse voranzustellen, nicht dem klassennamen.
manche machen C fuer classe und T fuer POD, aber daran aendert sich auch nix, wenn es millionen klassen gibt. und meist machen das auch nur mfcler und pascaller, also niemand, an dem man sich zu stark orientieren sollte.

japro

Original erstellt von Shade Of Mine:
und irgendwann weisst du, dass du die variable foo brauchst, aber du weisst nicht welches prefix sie hat. wars jetzt ein iFoo, uFoo, uiFoo, nFoo, unFoo?
und bei functions pointer wirds ja nur noch lustig.

hmm das ist doch kein argument... das ist genau das selbe problem wenn du keine UN machst und einfach vergessen hast was für ein typ die variable hatte oder ob sie nun lenght oder size geheissen hat...

ich denke nur, dass wenn man konsistente namen wählt das ganze verständlich genug sein sollte und dannstören die ständigen p i und weis ich das alles vor den variablebnnamen.

Shade Of Mine

Original erstellt von japro:
hmm das ist doch kein argument... das ist genau das selbe problem wenn du keine UN machst und einfach vergessen hast was für ein typ die variable hatte oder ob sie nun lenght oder size geheissen hat...

nicht ganz.
stell dir vor du hast 2 projekte am laufen.
im Projekt 1 wird zwischen unsigned int und int unterschieden -> ui und i als prefix, bei Projekt 2 ist es immer i.

nun bist du voll vertieft im projekt und weisst jetzt nicht ob du iSumme oder uiSumme nehmen musst. du weisst aber sehr wohl dass Summe ein unsigned int, oder zumindest int. das kann dir ja eigentlich egal sein wenn du schreibst (und oft ist es egal ob du jetzt nen unsigned, signed, long, short verwendest):

cout<<"die Summe betraegt"<<Summe;

OK du denkst bei 2 projekten geht das noch - stimmt. Aber du wirst nicht nur 2 Projekte haben sondern unzählige. und irgendwann wirst du alte projekte aufarbeiten müssen und dann kann es sein dass sich die UN ändert.

und wenn man den namen der variable vergessen hat, dann hilft einem die UN auch nicht.

junix

Ich hab den Thread nur mehr oder weniger überflogen und will jetzt einfach mal meine Meinung zu dem Thema hier äussern:

Ich finde präfixe blöd. Gerade wenn man Programmierhilfen verwendet die vielleicht alle member auflisten, dann kann ich davon ausgehen, dass die dinger nach Namen sondern nach typ sortiert sind. Macht die Suche ned grade gemütlicher. Allerdings muss ich sagen, dass die Dokumentation des Typs innerhalb des Variablennamens durchaus sinn macht.

Ich persönlich verwende Suffixe für diesen Zweck. Ich hänge an Variablennamen meistens getrennt durch einen underscore ('_') den Typ (wenn er kurz ist wie z.B. "int") oder eine Verkürzung des typs (wenn es sich um Klassennamen wie TStringList oder so handelt) an.

Meines erachtens hat - egal in welcher Form - das dokumentieren des Datentyps bei Variabeln erhebliche Vorteile. Um mal einige der wichtigsten zu nennen:

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.
Oben Genanntes gilt auch bei Fragen nach Überlauf oder ähnlichem, da man ja den bereich durch den Datentyp (z.B. int) gleich mitdokumentiert hat.
Ä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.
Prä-/Suffixe bieten eine gedankenstütze sowohl beim lesen als auch beim codieren.

Klar bedeuten Prä-/Suffixe Schreibarbeit. Allerdings denke ich ist es hier wie mit dem Formatieren von Quellen eine Stilfrage. Das Formatieren von Quellen bedeutet auch schreibarbeit, man gewinnt allerdings damit mehr Übersicht und das Ganze programm lässt sich einfacher lesen.

Ich hab hier lesen müssen dass es mit C++ egal sei, welchen typ man nehme vonwegen Templates und so. Und überhaupt prüfe der Compiler ob gültig sei was man schreibt.
Das ist fertiger Unfug! Solange C++ der Schweinesprache C entstammt, solange besitzt C++ die gleichen fahrlässigen probleme wie C da lösen Templates auch nichts. Würde man obiges Argument bei Ada oder Pascal oder anderen streng typerisierten Sprachen anführen müsste ich recht geben. Nicht aber bei C(++).

Was dokumentiert denn besser? Wenn ich schreibe

/* im Header:*/
int variableA = 0xFFFF;
char variableB = 0xFF;

/* Implemenitert wird: */
{
    ...
    variableB = variableA;
    ...
}

oder wenn ich schreibe

/* im Header:*/
int variableA_int = 0xFFFF;
char variableB_char = 0xFF;

/* Implemenitert wird: */
{
    ...
    variableB_char = variableA_int;
    ...
}

Beim ersten Beispiel kann man - ohne der Kenntnisse der Datentypen - die Risiken der Zuweisung nicht abschätzen. Der Compiler stört sich schon gar nicht dran. Bei der zweiten kommt jedem blinden die Zuweisung mehr als merkwürdig vor und zumindest wird er sich bewusst, was das überhaupt für folgen hat.

Ähnliches gilt für Pointer oder mehrfach pointer. Es ist doch sicher interessant zu wissen ob denn nun ein Zeiger nur ein Zeigerszeiger ist oder ob er ein Zeiger ist? Auch hier lässt sich dank der suffix/präfix vergabe bestimmen, wie weit der Weg zum Wert auf den Gezeigt wird ist (durch das Anhängen/Voranstellen von entsprechend vielen 'p' oder was auch immer)

so, nun weiss ichnicht mehr was ich noch schreiben wollte. Aber ich denke das reicht auch mal soweit.

Das ist vorläufig alles was ich dazu zu sagen habe.

-junix

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.

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