Stilfrage: C als Präfix für Klassen

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

WebFritzi

Ich hau immer ein "C" vor meine Klassennamen, und void-Pointer sind mir scheißegal!

DocJunioR

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

Kauz01

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.

Shade Of Mine

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

Kauz01

@Shade

*ggg*

Kauz01

@Shade

Wir haben in einem früheren C-Projekt so programmiert und hatten einen guten Grund dafür. Der ist aber sicher generell ungültig.

[edit]

denn das heisst ja, wenn 0 gleich i ist

Die Aussage "0 gleich i" ist äquivalent zu der Aussage "i gleich 0". Das stimmt generell.
[/edit]

[ Dieser Beitrag wurde am 21.03.2003 um 09:26 Uhr von Kauz01 editiert. ]

Shade Of Mine

Original erstellt von Kauz01:
Wir haben in einem früheren C-Projekt so programmiert und hatten einen guten Grund dafür. Der ist aber sicher generell ungültig.

OK, du meinst alte Compiler die bei einem if(i=0) nicht warnen? Zugegeben, dass ist n Problem - aber heutzutage irrelevant (zum Glück)

Kauz01

@shade

Der Warning-Level wurde reduziert. Das hatte auch einen Grund (keine Altlast), aber das führt hier zu weit.

volkard

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

Das war einmal. Ist als historisch anzusehen.

iwr haben dutzende Projekte am Laufen und überall ist der Code standardisiert.

Stamdardisierung ja. Aber doch nicht mit nutzlosen Buchstaben. Sonst passiert nur, daß man den Zeiger lpachb nennt, statt begin (long pointer to array of character named begin). Der name soll verraten, WELCHE BEDEUTUNG die Variable hat, nicht welchen TYP.

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.

Und hier sag ist einfach, daß die Wartbarkeit dadurch nicht erhöht wird. Und mit gotos hat das überhaupt nix zu tun.

@DocJunioR ich hab schonmal Code von dir gesehen und ich finde ihn sehr sehr unübersichtlich. Du programmierst auch eher so'n C und C++ mischmasch.

crass

Hi, bei der Erfindung von C++ hat man sich ne Menge Mühe gegeben daß eigene Datentypen(Klassen) so gemacht werden können, daß man sie nicht mehr von eingebauten Datentypen unterscheiden kann (Operatoren überladen...verkette Zuweisung von Variablen etc...)...warum sollte man bei der Benneung eines Typs jezt unbedingt sagen.."Vorsicht das is ne Klasse". Ich glaub net daß das im Sinn der Erfinder gewesen wäre. Und sieht noch scheiße aus..ich hasse Prefixe.

Gerard

also das 50 leute in firma xyz das auch so machen ist kein stichhaltiges argument.
die leute haben nicht die zeit sich mit solchen fragen zu bescheftigen, außerdem gild ja oft "never change a running system" d.h. in der steinzeit der programmierung werden irgend welche regel festgelegt und gelten noch bis heute

volkard

zu dem i==0 vs 0==i:
Ich versuche "ziemlich generell" die zu untersuchende variable allein auf eine seute zu stellen.
also
if(i==0)
und vor allem
if(abhebungsbetrag<kontoStand+kreditRahmen)
statt
if(abhebungsbetrag-kontoStand<kreditRahmen)
oder so.

ausnahme ist immer
while(x>=min && x<=max)
das schreib ich lieber als
while(min<=x && x<=max)

denkar wären auch sachen der art
if( f(x) == f(y) )
wobei f ein kleiner ausdruck ist, hier fällt mir nur kein sinnvolles beispiel ein. nur gemeine wie
if(x/10==y/10)//x und y sind int
,was ich gar nicht versuchen mag. nach x aufzulösen.

Kauz01

@Volkard

Der name soll verraten, WELCHE BEDEUTUNG die Variable hat, nicht welchen TYP.

Grundsätzlich mal richtig. In der Praxis bin ich aber ganz froh, wenn ich der Variable ansehe, ob ein (eigentlich nummerischer) Schlüssel an dieser Stelle als long oder als string abgelegt ist.
Wir können jetzt natürlich Diskussionen führen, ob so was generell nicht vorkommen sollte. Mit Generalisierungen ist das aber so eine Sache :).

volkard

Original erstellt von Kauz01:
Grundsätzlich mal richtig. In der Praxis bin ich aber ganz froh, wenn ich der Variable ansehe, ob ein (eigentlich nummerischer) Schlüssel an dieser Stelle als long oder als string abgelegt ist.

ok, es gibt fälle...
nubes schreiben gerne vor jeden zeiger ein p. vorteil: man sieht den fehler von if(pa==pb) wo ein if(*pa==*pb) gemeint war. mir isses auch schon vorgekommen, daß ich alte C-funktionen las (das sind die verkorksten apparate über mehrere bildschirmseiten), und auf seite 3 nicht mehr wissen konnte, was nu f war.
ob der schlüssel nu numerisch ist, ob da ne zahl oder ein string verwendet werden darf. ich weiß nicht, evtl läßt sich hier mit der recht strengen typprüfung was rausfischen. (wenn man ne mißratene API hat, die einem void* vollschreibt und typprüfung gar nicht andeutungsweise mag, sollte man auch mißratenen code damit bauen, sonst paßts gar nicht.)
aber vor allem: heute, wo funktionen 2 oder 3 und die dicken funktionen 6 zeilen haben oder trivial sind, kann man erwarten, daß die regeln zum guten programmieren sich leicht geändert haben zu damals.
(ich erinnere mich mit schaudern an klassen, die 30 attribute hatten! jo, da hab ich bezeichner mit n am anfang geliebt. kann aber sein, daß es vor allem daran lag, daß ich nicht 30 maximal 6-buchstabige bezeichner auseinanderhalten konnte.)

[/QUOTE]Wir können jetzt natürlich Diskussionen führen, ob so was generell nicht vorkommen sollte. Mit Generalisierungen ist das aber so eine Sache :).[/QUOTE]
genau, die sind nämlich alle falsch.