Stilfrage: C als Präfix für Klassen

Gerard

zu der zeit als die mfc gemacht wurde gab es keine namespaces, ms hat sich für ein C entschieden Borland für T
selbst wenn man für compilier entwikelt die keine namespaces können sollte man nicht C benutzen sondern etwas womit man nicht mit der MFC in konflikt kommen kann

nman

Ich würde überhaupt keine Präfixe verwenden sondern Klassennamen einfach nur groß schreiben.

Beispiel: Point, Line, Quad etc

Ich würde einen Namensraum verwenden. Das ist auf jedenfall übersichtlicher, als ein Präfix und mann kann sich manchmal mit using namespace arbeit ersparen.

DocJunioR

Ich weiß nicht, warum man sich darüber streiten kann..

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. Zumal sich meine Klassen häufig um die Bearbeitung einer Tabelle drehen, denen eine struct zugrunde liegt. hie hab ich dann den Vorteil, dass ich die zu bearbeitende struct gleich erkenne, die heißt nämlich - mal abgesehen vom präfix - genau wie die Klasse.

cYa
DjR

Shade Of Mine

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.

volkard

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!

DocJunioR

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

volkard

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

Gregor

...hört sich nach ner feindlichen Übernahme an!

Shade Of Mine

Original erstellt von DocJunioR:
Im privaten Bereich ist das vielleicht so.

Anmerkung: ich programmiere auch professionell -> zwar nur PHP, aber Klasse bleibt Klasse.

volkard

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

DocJunioR

@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 egal

cYa
DjR

Shade Of Mine

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 htmlMail(); und nicht$ 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;

DocJunioR

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

volkard

Original erstellt von DocJunioR:
@volkard: ich hab niemandem nie nichts nahegelegt

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

volkard

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.

kartoffelsack

in meinem forum meinen nubes

Guck mal auf das Hintergrundmuster in Deinem Forum :p

HumeSikkins

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