Stilfrage: C als Präfix für Klassen
-
Original erstellt von DocJunioR:
Es ist nicht unübersichtlich. Im Gegenteil, ich kann immer genau sagen, was klasse ist und was Struktur/Variable.es ist mir egal ob Int jetzt eine Klasse oder eine struct oder sonstwas ist (wobei struct und class in C++ ja nahezu identisch sind)
Ich weiss, dass ich mit
Int i(0);
cout<<i+5;5 ausgebe, das reicht mir.
die implementationsdetails sind unwichtig.
und das sehe nicht nur ich so, sondern so ziemlich jeder software entwickler den ich kenne.
-
Original erstellt von DocJunioR:
Ich persönlich benutze den Präfix C_ für Klassen, S_ für Strukturen und (wenn ich sie nutzen würde) U_ für Unions. Man kann noch so weit gehen, Variablen mit V_ und Parameter mit P_ zu unterscheiden. Bin ich allerdings zu faul zu.
Es ist nicht unübersichtlich. Im Gegenteil, ich kann immer genau sagen, was klasse ist und was Struktur/Variable.So ein Zufall!
Ich machs genau anders. Bei mir haben Typen große Namen und Variablen und Funktionen kleine.
Und structs nehm ich nicht, außer mal privaten structs wie Liste::Node. Und union auch nicht.
Und irgendwie weiß ich genau, was eine Klasse/Struktur und was Variable/Funktion ist. Da dann noch die Variablen entweder einbuchstabig sind oder Gegenstände bezeichnen, und die Funktionen Tätigkeiten, kann ich sogar die unterscheiden.inline S_Complex<double> operator+(S_Complex<double> P_a,S_Complex<double> P_b) { S_Complex<double> V_r; V_r.re=P_a.re+P_b.re; V_r.im=P_a.im+P_b.im; return V_r; }
rofl!
-
Im privaten Bereich ist das vielleicht so. Aber wenn man in einem etwas größeren Umfang programmiert, muss man sich an einige Konventionen gewöhnen. rein der dokumentation wegen..
Da hab ich doch neulich einen interessanten Kommentar gehört: "Die beste Doku ist mein Source" Zur Übersichtlichkeit gehören (nach meiner Meinung!) auch sprechende Variablen- und Typennamen. Naja, wie gesagt, ich möchte mich nicht mit Dir streiten, shade (hatten wir ja schon oft genug *gg*). Ich mach's wie ich es für angebracht halte und wenn Du sagst, es ist nicht Dein Ding, dann musst du's ja nicht machen
cYa
DjR
-
Original erstellt von DocJunioR:
Da hab ich doch neulich einen interessanten Kommentar gehört: "Die beste Doku ist mein Source" Zur Übersichtlichkeit gehören (nach meiner Meinung!) auch sprechende Variablen- und Typennamen.genau, und deshalb kein ungarisch!
Naja, wie gesagt, ich möchte mich nicht mit Dir streiten, shade (hatten wir ja schon oft genug *gg*). Ich mach's wie ich es für angebracht halte und wenn Du sagst, es ist nicht Dein Ding, dann musst du's ja nicht machen
mach meinetwegen mit shade ein stillhalteabkommen.
aber solange du in meinem forum meinen nubes sowas ans herz legst, werde ich widersprechen.
-
meinem forum meinen nubes
-
...hört sich nach ner feindlichen Übernahme an!
-
Original erstellt von DocJunioR:
Im privaten Bereich ist das vielleicht so.Anmerkung: ich programmiere auch professionell -> zwar nur PHP, aber Klasse bleibt Klasse.
-
Original erstellt von Gregor:
...hört sich nach ner feindlichen Übernahme an!freundlich.
[ Dieser Beitrag wurde am 20.03.2003 um 13:39 Uhr von volkard editiert. ]
-
-
@volkard: ich hab niemandem nie nichts nahegelegt
Ich hab gesagt,wie ich es mache. War schon immer dafür, dass jeder seine Meinung äußern sollte und denn muss man sich selbst ein Büld machen.
Sachemal, Shade. programmierst du alleine an den phps? Das kann ich dann noch verstehen. allerdings bei 50 Leuten, die an einem Projekt sitzen, ist das einfach sinnvoll, sich solche Richtlinien einfallen zu lassen.
Stell Dir vor, da ist jemand im Urlaub, das Projekt soll in zwei stunden eine Marke erreicht haben und in der Bibliothek des Urlaubers geht was schief. willst Du dich durch Variablennamen wie "w", "i", "z1, z2" durchkramen müssen?Ist im Endeffekt auch irrelevant, wie ich das im Einzelnen mache. Wichtig ist meines Erachtens(!), dass man sich gerade bei wichtigen Werten/Objeken/etc. klare Strukturierungen schafft und diese auch knallhart durchzieht. Wenn man sich das Leben durch kurze Erweiterungen erleichtern kann, warum nicht?
Wer ohne sowas klar kommt, der macht's halt nicht. Solange ich den Code nicht warten muss, isses mir eigentlich auch egalcYa
DjR
-
Original erstellt von DocJunioR:
Sachemal, Shade. programmierst du alleine an den phps? Das kann ich dann noch verstehen. allerdings bei 50 Leuten, die an einem Projekt sitzen, ist das einfach sinnvoll, sich solche Richtlinien einfallen zu lassen.
Stell Dir vor, da ist jemand im Urlaub, das Projekt soll in zwei stunden eine Marke erreicht haben und in der Bibliothek des Urlaubers geht was schief. willst Du dich durch Variablennamen wie "w", "i", "z1, z2" durchkramen müssen?wir sind 9 programmierer sowie ab und zu kommt n praktikant dazu.
variablennamen sind natürlich sinnvoll, aber Klassen haben kein Prefix:mail=new C_htmlMail();
die zweite zeile gibt mir keine zusatzinfos.
in C++ genau das selbe:
htmlMail mail;
oder
C_htmlMail mail;was weißt du über mail mehr? nichts, htmlMail muss ja ne class sein (oder meinetwegen auch ne struct).
sinnvoll ist es dagegen den klassen aussagekräftige namen zu geben.
zB
DB db;
ist nicht sonderlich sinnvoll.
da tendiere ich zu
Database db;
-
Weißt du, shade, wir können hier noch Wochen diskutieren und zu keinem kompromiss kommen.
Gegenbeispiel:
Ich habe eine Tabelle, die beispielsweise Personaldaten beinhaltet.
struct S_Personal
{
char Name[30];
char Vorname[30];
char Adresse[100];
..
};Wenn ich mir eine Klasse zur Verwaltung der passenden Datei(en) baue, nenne ich sie grundsätzlich C_Personal. Das hat einfach den Grund, dass ich weiß, worauf die Klasse zugreift. Ich weiß, dass die Klasse hauptsächlich mit der Struktur S_Personal arbeitet. Sämtliche anderen Strukturen, die in der Klasse vorkommen, verändern nicht die Stammdaten der zugehörigen Tabellen. Das erspart mir einfach eine Menge Dokumentationsarbeit.
Das mag dir vielleicht nicht sinnvoll vorkommen, mir jedoch schon und warum sollte ich alles machen wie du? Ich kann meinen Code lesen, und darauf kommt es mir an. Außerdem wird von mir niemand gezwungen, sowas zu machen, es sei denn, er arbeitet an meinem Projekt mit<Vorschlag>
Was haltet Ihr davon, wenn wir darin übereinkommen, dass es zumindest sinnvoll ist, sich Regeln zu erstellen, nach denen man seine Objekte, etc. programmiert? Selbst wenn man zum Ergebnis kommt, dass man sowas nicht machen muss, hat man sich wenigstens Gedanken gemacht und das ist das Wichtige an der Sache.
</Vorschlag>[ Dieser Beitrag wurde am 20.03.2003 um 15:03 Uhr von DocJunioR editiert. ]
-
Original erstellt von DocJunioR:
@volkard: ich hab niemandem nie nichts nahegelegtmal gucken
allerdings bei 50 Leuten, die an einem Projekt sitzen, ist das einfach sinnvoll, sich solche Richtlinien einfallen zu lassen.
ha, erwischt? ist das keine nahelegung?
Stell Dir vor, da ist jemand im Urlaub, das Projekt soll in zwei stunden eine Marke erreicht haben und in der Bibliothek des Urlaubers geht was schief. willst Du dich durch Variablennamen wie "w", "i", "z1, z2" durchkramen müssen?
De begründest deine unsinnigen Klassenpräfixe mit Argumenten, die nix und überhaupt nix mit Klassenpfäfixen zu tun haben. Klar sind Variablen so zu benennen, daß man sich was drunter vorstellen kann.
beachte zum Beispiel mal folgenden Unfug:
Auto a;
Personal chef;
Gut wäre
Person chef, denn der chef ist eine Person.
Nett ist auch vector<Person*> personal.
Aber ne Klasse namens Personal kann es nicht geben.
Und nu, wo das geklärt ist, ist auch klar, daß es keine S_Personal oder C_Personal geben kann. Und selbst wenn, dann niemals beide!!! Niemals! Denn ne Person ist ne Person ist ne Person. Stammdaten? Tabellen? Deine Personen sind nur Interfaces zu ner relationalen Datenbank drunter? Sind es dann Personen?
-
Original erstellt von DocJunioR:
**<Vorschlag>
Was haltet Ihr davon, wenn wir darin übereinkommen, dass es zumindest sinnvoll ist, sich Regeln zu erstellen, nach denen man seine Objekte, etc. programmiert? Selbst wenn man zum Ergebnis kommt, dass man sowas nicht machen muss, hat man sich wenigstens Gedanken gemacht und das ist das Wichtige an der Sache.</Vorschlag>
**Nee.
Nicht mit Leuten, die daran denken, sich dann auch erbittert dran zu halten.
Alle Generalisierungen sind nämlich falsch.
Die Hauptregel beim Proggen ist, daß man jede Regel irgendwann und irgendwo verletzen sollte, um zu guten Ergebnissen zu kommen.
Wir könnten höchsten drüber nachdenken, ob es sinnvoll ist, sich manche Sachen anzugewöhnen. Und welche gewohnheiten eher gut und welche eher schlecht sind.
ich fang an mit: void-pointer sind schlecht, klassenpräfixe sind schlecht und #defines sind schlecht.
-
in meinem forum meinen nubes
Guck mal auf das Hintergrundmuster in Deinem Forum :p
-
ich fang an mit: void-pointer sind schlecht
Wie gemein. Gerade habe ich void-Pointer benutzt um dir ein schönes foreach zu programmieren
<Achtung>
Meine Aussage soll kein Widerspruch zu Volkards Aussage darstellen.
Ich halte void-Pointer natürlich auch für schlecht.
</Achtung>[ Dieser Beitrag wurde am 20.03.2003 um 23:20 Uhr von HumeSikkins editiert. ]
-
Ich hau immer ein "C" vor meine Klassennamen, und void-Pointer sind mir scheißegal!
-
Wie gesagt, ich mach's so. wenn ihr mich dafür lynchen wollt, gerne. Zumindest Fritzi kann meinen Code schon auf den ersten Blick lesen
Habt ihr mal in ner größeren firma programmiert? Da sind die Variablennamen sogar nach Datentypen, Nutzung und Länge bezeichnet und meine 'Firma' besteht nicht nur aus 10 Leuten. iwr haben dutzende Projekte am Laufen und überall ist der Code standardisiert. Wenn ihr's nicht einseht, ist das nicht mein Problem *fg*
Es sieht am Anfang umständlich aus, aber wenn man erstmal dazu kommt, code lesen zu müssen, der schon 10 Jahre alt ist, wird man solche Konventionen lieben. Der einzige Grund, warum man sowas überhaupt macht, ist die Wartbarkeit. Wäre dies nicht nötig, würden wir noch regelmäßig jumps/gotos machen.Ich habe immernoch nie nicht niemandem was nahegelegt. ich sagte nie :"volkard, mach das so!" ich hab nur meine Meinung öffentlich geäußert. Okay, dafür wird man in letzter Zeit unter anderem auch gelyncht, abgesägt und ähnliches, aber egal. Meine Meinung kennt ihr, ich mach's so, wenn ihr nicht, isses mir auch egal. Hauptsache, ihr kommt mit klar
cYa
DjR
-
Volkard schrieb:
Alle Generalisierungen sind nämlich falsch.
Da erinnere ich mich doch daran, dass ich mit dir und Shade gestritten habe, ob es Fällen geben könnte in welchen es sinnvoll sein [b|könnte[/b]
0 == i
statt
i == 0
zu schreiben. Das wurde aber von dir (und Shade) generell abgelehnt.
Meine persönliche Meinung zum eigentlichen Thema dieses Threads:
Bei uns werden Präfixe verwendet und ich bin oft sogar in meinem eigenen Code froh, dass ich auch nach zwei Jahren noch schnell erkennen kann, worum es sich handelt.
Leute mit besserem Gedächtnis (oder kleineren und kürzeren Projekten) als meinem brauchen so was sicher nicht.Wie schon bemerkt: Dies ist meine Meinung und kein Evangelium für irgendwelche Programmierer. Ich bin bisher gut damit gefahren und werde auch weiterhin so programmieren, weil ich für mich Vorteile sehe. Wer anders vielleicht sogar besser zurecht kommt, soll es anders machen.
-
Original erstellt von Kauz01:
**Da erinnere ich mich doch daran, dass ich mit dir und Shade gestritten habe, ob es Fällen geben könnte in welchen es sinnvoll sein [b|könnte[/b]0 == i
statt
i == 0
zu schreiben. Das wurde aber von dir (und Shade) generell abgelehnt.
**das ist etwas anderes.
es gibt generalisierungen die immer stimmen.
zB:
im Krieg sterben Menschen
und
0==i
gegen
i==0
da ist 0==i semantisch falsch.
denn das heisst ja, wenn 0 gleich i ist
es interessiert mich aber nicht was 0 ist, sondern was i ist.aber darum geht es jetzt nicht