Designfragen

[knivil]

WeissNixKannNix schrieb:

Nachtrag: Das obwen soll Standard heißen, warum er da zensiert hat, ist mir schleierhaft (hab's zuvor mit T geschrieben)...

Weil es falsch geschrieben ist. Es heisst Standard. Genau wie vorraus.

[Nukularfüsiker]

WeissNixKannNix schrieb:

Viele stellen der Klasse ja ein 'C' voran, dem Struct ein 'S', dem Enum ein 'E', Membervariablen kriegen dann je nach typ einen Prefix wie m_p oder m_b.

Nennt sich (falsche) Ungarische Notation.

Wie sollte man's denn nun am besten machen?

Frag 3 Leute und du bekommst 4 verschiedene Meinungen.

[Dravere]

WeissNixKannNix schrieb:

Ist das eigentlich ein stan****? Wie sollte man's denn nun am besten machen?

Immer so, wie es einem am besten passt. Man es also am besten lesen und warten kann, bzw. wenn man im Team arbeitet, dann wie es das Team am besten lesen und warten kann.

Standards gibt es nicht, es gibt nur Konventionen und Richtlinien, welche unterschiedlich eingehalten wird. Es gibt zum Beispiel die ungarische Notation, die heutzutage aber stark umstritten und fraglich ist, vor allem weil Microsoft diese Notation falsch interpretiert hat und somit eine falsche ungarische Notation sehr bekannt wurde.

Ich persönlich probiere mich inzwischen an einer ganz neuen Notation: Ich übernehme die Notation von der Standardbibliothek der jeweiligen Sprache. Sinn und Zweck davon ist Einheitlichkeit. Es sieht einfach schrecklich aus, wenn unterschiedliche Notationen gemischt werden. Da es sowieso mehr eine subjektive Angelegenheit ist, ist es meistens nur eine Gewohnheitssache.

Grüssli

[asc]

WeissNixKannNix schrieb:

Ich würde gern mal wissen, wie Ihr Eure Namensgebung in C++ gestaltet. Viele stellen der Klasse ja ein 'C' voran,...

Viele möchte ich nicht unterschreiben. In der Anfangszeit war die ungarische Notation noch recht gebräuchlich, die mit Präfixen gearbeitet hat. Und in der Zeit als es noch keine Namensräume gab hat die MFC ein C, die VCL ein T vor Klassen gesetzt - dies wurde von vielen übernommen, womit die Eindeutigkeit wieder Geschichte war.

Grundsätzlich gibt es im wesentlichen 2 große Lager: Befürworter der ungarischen Notation (nach meiner Erfahrung schwindet dies in C++ aber immer mehr), und auf der anderen Seite die, die Sagen das Typinformationen nur dann in dem Namen auftauchen sollten, wenn es wirklich wichtig ist, und eher den wesentlichen Gesichtspunkt auf die Lesbarkeit legen. Es gibt noch Abstufungen dazwischen, wie z.B. die, die Membervariablen markieren, oder Zeiger, aber sonst z.B. nichts.

Ich lehne die ungarische Notation z.B. ziemlich in der Gänze ab (übrigens war ich - lange her - ein Befürworter), ich unterscheide auch nicht nach Member- und Nichtmembervariablen (Da ich grundsätzlich versuche eher kleine Methoden zu schreiben, ist es auch überschaubar, falls nötig setzte ich ein this-> davor), nur bei Zeigern kommt es gelegentlich noch zu einem p Davor, auch wenn ich inzwischen selbst davon abrücke.

Gründe:
1. Gibt es z.b. keine Unterschiede in C++ zwischen Klassen und Strukturen, außer der Standardsichtbarkeit.
2. Machen Präfixe und Postfixe (zumindest meiner Erfahrung nach) Programme schwerer lesbar.
3. Gibt es in nahezu allen Modernen Sprachen die Möglichkeit eigene Typen zu definieren, und dann gehen recht schnell die Präfixe aus, oder werden irgendwann zu kryptisch.
4. Gerade in C++, wo auch Templates verwendet werden, kann man in bestimmten Kontexten garnicht mehr sagen um was für einen Typ es sich handelt.
5. Man ändert durchaus mal den Typ einer Variable, und müsste dann immer wieder alles anpassen.
6. Nach meiner Erfahrung wird gerne bei Verwendung von Präfixen/Postfixen auch gerne die Bedeutung zusammen gestutzt. Dies ist zwar nicht notgedrungen so, scheint aber leider noch recht verbreitet zu sein.
...

Ich persönlich verwende im wesentlichen die Variante wie sie in den C# Richtlinien stehen: CamelCase für Typen, pascalCase für Variablen, REINE_GROSSSCHREIBUNG für Makros, und benenne zudem die Variablen nach ihrer Bedeutung (z.B. anzahlRaeume, istPersistent...), nicht nach ihrem Typ.

[pumuckl]

Ich halte es da genauso wie asc, zumindest in privaten Projekten wo ich das entscheiden darf. Unter anderem, weils an mehreren Stellen so empfohlen und in vielen Büchern auch gelebt wird, unter anderem bei Herb Sutter (ja, ich bin Fan ).

Dravere schrieb:

Ich persönlich probiere mich inzwischen an einer ganz neuen Notation: Ich übernehme die Notation von der Standardbibliothek der jeweiligen Sprache. Sinn und Zweck davon ist Einheitlichkeit.

Ich mache das bewusst nicht. Wenn in meinem Quelltext eine Funktion oder ein Variablenname mit under_score_namen verwendet wird, ist sofort klar, dass es sich um ein Element aus der Standardbibliothek oder boost handelt - oder einer anderen Bibliothek die solche Notation verwendet. Da ich eh höchst selten bzw. nie mehr als ein oder zwe zusätzliche Bibliotheken zu den beiden im gleichen Code verwende, wirds auch nicht zu uneinheitlich.

[Gast]

asc schrieb:

Ich persönlich verwende im wesentlichen die Variante wie sie in den C# Richtlinien stehen: CamelCase für Typen, pascalCase für Variablen, REINE_GROSSSCHREIBUNG für Makros, und benenne zudem die Variablen nach ihrer Bedeutung (z.B. anzahlRaeume, istPersistent...), nicht nach ihrem Typ.

Das mache ich genau so. Habe es aber nicht von C#, sondern von Java abgeguckt.

[volkard]

pumuckl schrieb:

Ich halte es da genauso wie asc, zumindest in privaten Projekten wo ich das entscheiden darf. Unter anderem, weils an mehreren Stellen so empfohlen und in vielen Büchern auch gelebt wird, unter anderem bei Herb Sutter (ja, ich bin Fan ).

Dravere schrieb:

Ich persönlich probiere mich inzwischen an einer ganz neuen Notation: Ich übernehme die Notation von der Standardbibliothek der jeweiligen Sprache. Sinn und Zweck davon ist Einheitlichkeit.

Ich mache das bewusst nicht. Wenn in meinem Quelltext eine Funktion oder ein Variablenname mit under_score_namen verwendet wird, ist sofort klar, dass es sich um ein Element aus der Standardbibliothek oder boost handelt - oder einer anderen Bibliothek die solche Notation verwendet. Da ich eh höchst selten bzw. nie mehr als ein oder zwe zusätzliche Bibliotheken zu den beiden im gleichen Code verwende, wirds auch nicht zu uneinheitlich.

Genau.

Ich mache sogar wiederverwendungsgeplanten Code auf englisch und kundenprojektspezifischen Code auf deutsch. Ja, ich weiß, da fangt ihr gleich an zu weinen, weil es sehr unprofessionell iat. Aber die Schichtentrennung ist hilfreich.

[Nexus]

asc schrieb:

Ich persönlich verwende im wesentlichen die Variante wie sie in den C# Richtlinien stehen: CamelCase für Typen, pascalCase für Variablen, REINE_GROSSSCHREIBUNG für Makros, und benenne zudem die Variablen nach ihrer Bedeutung (z.B. anzahlRaeume, istPersistent...), nicht nach ihrem Typ.

Genau so mache ich es auch. Ich hatte eine Zeit lang auch für Variablen CamelCase verwendet, bin nun aber davon abgekehrt. Allein schon wegen Object object (statt irgendwelchen künstlichen Bezeichnern), aber natürlich auch sonst finde ich Code übersichtlicher.

Für Funktionen und Klassen unterschiedliche Konventionen zu haben, gefällt mir nicht so sehr. Auch den Standard-Stil verwende ich eigentlich nur, wenn etwas kompatibel sein muss (z.B. STL-artige Schnittstelle).

[hürxenbu]

volkard schrieb:

Ich mache sogar wiederverwendungsgeplanten Code auf englisch und kundenprojektspezifischen Code auf deutsch. Ja, ich weiß, da fangt ihr gleich an zu weinen, weil es sehr unprofessionell iat. Aber die Schichtentrennung ist hilfreich.

Schreib deinen kundenspezifischen Code wiederverwendbar.

[asc]

hürxenbu schrieb:

volkard schrieb:

Ich mache sogar wiederverwendungsgeplanten Code auf englisch und kundenprojektspezifischen Code auf deutsch. Ja, ich weiß, da fangt ihr gleich an zu weinen, weil es sehr unprofessionell iat. Aber die Schichtentrennung ist hilfreich.

Schreib deinen kundenspezifischen Code wiederverwendbar.

Ich habe die Erfahrung gemacht das es sehr viele Kundenwünsche gibt, die sehr speziell sind, und nur für diesen Kunden zutreffen. Man kann einiges verallgemeinern, aber es gibt immer wieder Dinge, die nur und ausschließlich für einen Kunden relevant sind (und andere Kunden auch nicht optional haben wollen).

Das kann schon mit speziellen Maskenwünschen einhergehen, in dem die bisherige Bedienung komplett umgekrempelt wird (was viele Kunden dir anschließend um die Ohren hauen würden, wenn du dies "verallgemeinerst"), oder mit speziellen Bewertungsregeln die nur und ausschließlich in Firma xyz so vorgenommen wird.

[Dravere]

@Threadersteller,
Siehst du? Ganz unterschiedlich

pumuckl schrieb:

Ich mache das bewusst nicht. Wenn in meinem Quelltext eine Funktion oder ein Variablenname mit under_score_namen verwendet wird, ist sofort klar, dass es sich um ein Element aus der Standardbibliothek oder boost handelt - oder einer anderen Bibliothek die solche Notation verwendet. Da ich eh höchst selten bzw. nie mehr als ein oder zwe zusätzliche Bibliotheken zu den beiden im gleichen Code verwende, wirds auch nicht zu uneinheitlich.

Wozu muss man dies erkennen können? Sowas sticht ins Auge und stört den Lesefluss, wie ich persönlich finde.
Hab diese Notation aktuell vor allem für meine C# Projekte verwendet, was mir sehr gefallen hat, dass der ganze Code einheitlich ist und nicht mal irgendwo plötzlich mal wieder etwas seltsam anders aussieht und man im Lesefluss stockt.

Grüssli