Thema: "Naming Conventions" (mein Tip!)

[Mario Sandler]

Also hier mal meine naming_rules:
Methoden werden mit Verben benannt: read(), write()...
Variabeln mit Substantiven: counter, number, result...
const-Variabeln mit großen Substantiven: PI, MWST...
Klassen embenfalls mit Substantiven allerdings der erste Buchstabe groß: Car, House, Question...

Ansonsten alles wie es einem passt, wenns geht aber auf englisch und mit höchstens 2-silben.

Jedes größere Regelwerk verwirrt nur anstatt das es hilft.

[volkard]

1310-Logik schrieb:

volkard schrieb:

ich denke schon, daß jede katze ein säugetier und jedes säugetier ein wirbeltier ist.

Du denkst..ja aber weisst Du es auch?

scherzkeks. wie doof willste mich denn darstellen? und unerheblich isses auch, denn am ende programmiere ich ja nur ein modell und nicht die welt selbst. eine kleine welt, wo wale fische sind und pinguine keine vögel.

im übrigen schließe ich mich Storm.Xapek.de an.

[THX 1138]

volkard schrieb:

eine kleine welt, wo wale fische sind und pinguine keine vögel.

aber ne katze ist ein säugetier, ja?

Nein im ernst, ich will Dir keine Dummheit unterstellen.
Aber wenn Gott einem Programmierkollegen seine Schöpfung zeigt, weiss der nicht dass ne Katze ein Säugetier ist, ausser in der Dokumentation ist ein Stammbaum drin. (aus dem DNA Code wär das noch ersichtlich, doch besonders Lesbar ist der nicht ATGGTGCTG..)

Und was ist nun mit dem Hasen Problem? Ich bin gerne einsichtig, aber wenn ich statt Hasenpopulation Rotte, und statt Graspopulation Wiese schreib, hab ich spätestens bei Füchsen das Problem, das die keine Rudeltiere sind.

[C++ Forumbot]

Dieser Thread wurde von Moderator/in estartu aus dem Forum MFC (Visual C++) in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[Michael E.]

1310-Logik schrieb:

volkard schrieb:

eine kleine welt, wo wale fische sind und pinguine keine vögel.

aber ne katze ist ein säugetier, ja?

Ja, siehe Basisklasse. Da gibts nix rumzudeuten. Wo kommen wir denn da hin, wenn ich ne Basisklasse Säugetier hab, die ne Basisklasse Tier hat, die ne Basisklasse Lebewesen hat. Ich nenn keine Klasse lebewesen_tier_saeugetier_katze_wildkatze_tiger_saebelzahntiger.

Aber wenn Gott einem Programmierkollegen seine Schöpfung zeigt, weiss der nicht dass ne Katze ein Säugetier ist, ausser in der Dokumentation ist ein Stammbaum drin.

Oder er schaut sich die Definition an. Wo ist das Problem?

Und was ist nun mit dem Hasen Problem? Ich bin gerne einsichtig, aber wenn ich statt Hasenpopulation Rotte, und statt Graspopulation Wiese schreib, hab ich spätestens bei Füchsen das Problem, das die keine Rudeltiere sind.

Mehrere Hasen sind ein Array von Hasen, dafür gibts keine eigene Klasse.

[bluecode]

1310-Logik schrieb:

(aus dem DNA Code wär das noch ersichtlich, doch besonders Lesbar ist der nicht ATGGTGCTG..)

OT: Gibts auch Viecher die als DNA nur TGGCTGGCTGGC haben? Wie heißen die?

Ansonsten find ich es auch überflüssig die Basisklasse vorneanzuhängen... is sehr unübersichtlich... va. wenn man sowieso ne doxygen doku hat *tipp*

[THX 1138]

Michael E. schrieb:

Und was ist nun mit dem Hasen Problem? Ich bin gerne einsichtig, aber wenn ich statt Hasenpopulation Rotte, und statt Graspopulation Wiese schreib, hab ich spätestens bei Füchsen das Problem, das die keine Rudeltiere sind.

Mehrere Hasen sind ein Array von Hasen, dafür gibts keine eigene Klasse.

ein Hasen-Array ist noch keine Rotte, ansonsten kannst Du mir vielleicht da weiterhelfen..

[Michael E.]

Tja, dann gibts halt keine Fuchsrudel-Klasse. Ich seh immer noch nicht dein Problem.

[THX 1138]

Rudel_Fuchs != Füchse

[bluecode]

ja und? Warum heißt die Klasse dann in dem Fall net einfach fuchs_rudel? Anstatt lebewesen_tier_***********_rudel_fuchs bzw. wie machst des überhaupt bei mehreren Basisklassen?

[Mario Sandler]

hä????
von was redet ihr da? rudel, füchse... bleiben wir doch bei realitätsnahen Beispielen. Es ist ja klar das bei rudel_füchsen und füchsen keiner durchblcikt!

[THX 1138]

sorry..das ist mein realproblem (siehe da)
ausserdem schreib ich nur population_fox und lifeform_fox.
mehrfachvererbung mach ich grad noch nicht.
kritisieren und irgendwelche satanarchäolügenialkohöllischen wortverkettungen erfinden kann jeder. ich versuch mich nur in meinem filechaos zurecht zu finden.
ich sagte aber auch, bin für vorschläge einsichtig genug, und warte auf vorschläge!

...sorry ist nur meine meinung. nicht sein

[THX 1138]

bluecode schrieb:

ja und? Warum heißt die Klasse dann in dem Fall net einfach fuchs_rudel? Anstatt lebewesen_tier_***********_rudel_fuchs bzw. wie machst des überhaupt bei mehreren Basisklassen?

Füchse sind gar keine Rudeltiere...und wale keine fische

aber über style und konventionen lässt sich nicht streiten.
hab die profis unter euch schonmal gefragt, ob sie firmeninterne richtlinien haben, wär mal interessant wies im realen leben gehandhabt wird, und nicht in der theorie sein sollte.

[jemand ...]

Das ist mit Abstand die dämlichste Namenskonvention, die ich je gelesen habe, denn sollte es tatsächlich zu Namenskonflikten kommen (ob nun vom Compiler aus, oder einfach weil es möglicherweise weitere Programmierer verwirren könnte), dann geb ich halt einfach den voll qualifizierten Namen, inkl. Namespaces/Packages an.

[rapso]

wir haben eine StyleGuide an die wir uns halten müssen. Ich finde, dass es nicht so sonderlich wichtig ist, dass jemand einen Style verfolgt, sondern dass in einer Firma alle den selben Style schreiben damit man mit fremden source arbeiten kann. denn wenn man an einen style nicht gewöhnt ist, kann sich schneller ein fehler einschleichen.
wir haben die Styleguid am anfang noch öfter umgeändert, z.b. gab es nen prefix für primitive datentypen iCount, pstrName, aber das war eher störend.

was für das arbeiten öfters wichtig ist, ist zu wissen ob es eine normale var ist, ein pointer oder eine referenz, deswegen haben wir als prefixe für namen r oder p z.b. pTorte->Fuellung(); bzw rTorte.Fuellung(); und Torte.Fuellung(); für autopointer hat sich ap eingeschlichen.

Desweiteren haben wir prefixe für namespaces(N) structs(S) classen(C) abstrakteclassen/interfaces(I) und enums (E) um bei typennamen gleich erkennen zu können wie die anwendung ist.

wörter werden mit grossbuchstaben angefangen z.b. MeineKleineVariable; wenn es member sind, gibt es ein m_ prefix, früher gab es noch für parameter den zwang sie mit kleinbuchstaben anzufangen, aber das sah dann sehr inkonsisten aus und hatte keinen wirklich nutzen, denn ob es eine lokale variable oder ein parameter-by-value hat keinen unterschied eigentlich.

es ist verboten "magic numbers" zu nutzen, jede konstante muss deklariert werden, dabei kann man entwoder
enum{MEINEZAHL = 5}; oder
const unsigned int MEINEZAHL=5; schreiben.
bei aufzählungen von konstanten darf man unterstriche zur abtrennugn der aufzählung nutzen
const unsigned int SIZE_X=1024;
const unsigned int SIZE_Y=1024;

grundsätzlich dürfen namespaces nicht global geöffnet werden. der sourcecode muss ohne dokumentation lesbar sein, manche speziellen (überschaubaren) spezialitäten sollen mit nem kurzen hinweis versehen werden z.b.
x=x>>15;//div by 32768

interfaces müssen mit einem kommentar versehen sein die mit doxygen zu einer doku konvertierbar sind.

alle namen und schriftlichen dinge in zusammenhang mit code müssen english sein (z.b. namensgebung von varialben und funktionen)

naja, mehr fällt mir nicht ein, da gibt es noch so kleine dinge wie "const int& rValue" statt "const int &rValue" weil int& ein datentyp ist... aber oben stehen die dinge die mir am wichtigsten erscheinen

naja, wie bei allen dingen waren alle am anfang sehr dafür sich daran zu halten, mittlerweile schreibt die hälfte doch wieder code der ihnen den arbeitsplatz sichert.

btw. natürlich sind verpönte dinge wie this->, goto, magicnumbers, usw. verboten

[THX 1138]

danke man, dassist mal ein klares statement

rapso schrieb:

naja, wie bei allen dingen waren alle am anfang sehr dafür sich daran zu halten, mittlerweile schreibt die hälfte doch wieder code der ihnen den arbeitsplatz sichert.

ich schreib in meine protokolle auch nicht die feinen handling tipps, die über oder der zellen entscheiden *ganzfiesgrins*

[N00B37530894650]

was ist denn an this-> so falsch??

[akari]

Hallo

das this-> überflüssog ist, wenn Member der Klasse korrekt von Parametern getrennt benannt werden.

bis bald
akari

[rapso]

N00B37530894650 schrieb:

was ist denn an this-> so falsch??

falsch ist nichts daran, es ist nur überflüssig, genau so überflüssig wie

void SetLightCount(int C);
int  GetLightCount()const;
//oder
void SetLight0();
void SetLight1();
void SetLight2();
...

im vergleich zu

void LightCount(int C);
int LightCount()const;

man darf auch this->this-> verwenden, klar. das alles ist nichtmal ein warning wert. deswegen ist es ja auch eine "StyleGuide" und kein c++standard.

aber neben dem standard gibt es auch gewisse paradigmen an die man sich hällt, weil man ja irgendwie auf einen konsens kommen muss. einer dieser ist dass man code minimalistisch schreibt. das heißt "nicht mehr als nötig", das heißt nicht, dass es nur noch a000 bis a999 als vars gibt.
dabei ist this-> wirklich total überflüssig, es ist möglich (wie so viele anderen dinge auch), aber überflüssig... daneben ist es aus meiner persönlich sicht auch unschön die ganze zeit einen pointer auf sich selbst zu verwenden.

[Reyx]

Dieses ewige Gepräfixe kann ich nicht nachvollziehen: Ich benutze eigentlich nur noch die von Java bekannten Namenskonventionen: Einfach, unkompliziert und vor allen Dingen nicht gezwungen; die Variablen behalten ihre natürlichen Namen!

Wenn ich in einer statisch typisierten Sprache programmiere brauche ich keine Präfixe wie "i" für int oder "d" für Double, in einer dynamisch typisierten kann es mir hingegen wurscht sein, weil ich es eh ständig prüfen muss. Pointer, Referenz oder was auch immer ist mir dabei ziemlich egal: Ich bin noch nie in eine Situation gekommen, wo mein Code irgendwie missdeutlich in dieser Hinsicht war, bzw. ich einen etwaigen Defizit nicht durch einen kleinen Kommentar ausmerzen konnte.

"C" für Klassen halte ich für idiotisch, denn wenn ich die Klasse schon benutze, dann weiß ich auch, dass es eine ist. Anders herum zeigt mir meine IDE sofort an, wenn ich es z.B. mit einem enum zu tun habe -> Wozu also ein Prefix? Auch Namespaces sollten mir bekannt sein, wenn ich damit umgehe, bzw. macht es mir jede moderne IDE auch relativ einfach zu erkennen, ob ich mit 'ner variable vom Typ void* agiere oder doch nur einen Namespace unter einem bestimmten Namen erreiche. Klassenmember mit einem Prefix zu vershen halte ich für krank: Dadurch, dass sie einer Klasse untergeordnet werden, sind sie bereits eindeutig als Member der Klasse klassifiziert; was soll da noch irgendeine künstliche Benennung? Ich schreibe ja auch nicht "Auto::autoReifen" oder "Auto::memberAutoReifen". Wo würde man da denn auch hin kommen!? (Auto::memberAutoReifen::membersMemberAutoReifenProfil::membersMembersMemberAutoReifenProfilTiefe [...])

Eure Namenkonventionen erinnern mich, wenn auch nicht so restriktiv, doch sehr an einen Abklatsch der Ungarischen Notation!

Was this betrifft: Wer's meint zu brauchen, der benutzt es halt, und wer nicht, halt nicht. Vorteilhaft ist es nur bei globalen Variablen oder zum eindeutigen ansprechen von überlagernden Variablen ... anderswo würde ich es aber auch nicht anwenden.