Namesgebung für klasseninterne Variablen

ingobulla

Hallo,
ich frage mich, welche Namenskonvention man am besten für klasseninterne Variablen verwendet. Gegeben sei also z.B. eine Klasse classification

class classification
{
private:
	int num_crfs_i;
public:
	classification();
	classification(const int no, const int num_sites_para);
	int num_crfs() const { return num_crfs_i; } 	
};

Es geht nun um num_crfs_i bzw. num_crfs(): Das erste ist die interne Variable (deshalb "_i" am Ende), die die "number of circulating recombination forms" repräsentiert, das zweite die Funktion, die sie nach außen gibt. Da beide nicht gleich heißen können, habe ich mich erstmal dafür entschieden, an den Namen der internen Variable das "_i" am Ende anzuhängen.

Meine Frage ist nun, welche bewährten Namenskonventionen es für diese Situtation gibt, die die Lesbarkeit des Codes maximieren (ich bezweifele, dass meine Variante das Optimum darstellt). Oder lässt sich das Problem noch anders als durch geschickte Namensgebung lösen?

drakon

Also es wird einfach ein m_ .. angehängt, um die Member darzustellen.

also z.B:

class foo{
private:
   int m_iVar;
   DWORD m_dwVar2;
};

usw. der Rest wird einfach nach der ungarischen Notation oder so, wie du es sonst machst gelöst. Finde ich persönlich noch recht praktisch so, so siehst du immer gerade, dass eine Variabel zu einer Klasse gehört.

EDIT:

http://de.wikipedia.org/wiki/Ungarische_Notation
Hier siehst du das mit dem m_.. unten auch nochmal.

asc

drakon schrieb:

Also es wird einfach ein m_ .. angehängt, um die Member darzustellen.

...

usw. der Rest wird einfach nach der ungarischen Notation oder so, wie du es sonst machst gelöst. Finde ich persönlich noch recht praktisch so, so siehst du immer gerade, dass eine Variabel zu einer Klasse gehört...

Du solltest aber auch erwähnen das die ungarische Notation auch sehr viele Gegner grade auch unter C++ hat. Ich will hier jetzt nicht das Gefecht bis in den letzten Punkt ausfechten, aber zumindestens der Vollständigkeit halber noch Gründe dagegen nennen und Alternativen nennen. Der OP kann sich ja selbst aussuchen was für ihn das Beste ist.

So wesentliche Gründe gegen die ungarische Notation:
a) Die ungarische Notation ist eine zweite "Sprache" die man beherrschen muss um damit wirklich etwas anfangen zu können.
b) Bei Templates, Generics etc. lässt sich der Variablentyp nicht im Vorfeld bestimmen.
c) Zumindestens in den Projekten in denen ich saß haben die Verfechter der ungarischen Notation auch gerne an beschreibeden Namen geknausert. Dies ist kein Zwang und muss nicht so sein, aber wird gerne damit argumentiert das man dies ja über den krytischen Präfix ablesen kann.

Zu den Alternativen:

1. Durch sprechende Namen und Moderne Entwicklungsumgebungen kann man auch ohne eine zweite Sprache den Code sinnvoll lesbar machen. Ich halte folgendes z.B. auch ohne UN für lesbar:

if(isEmpty)
  throw(EmptyListException());
std::size_t personCount = personList.count();

2. Wie kann man Member auch ohne m_ kenntlich machen?

Eine Möglichkeit ist die folgende (die imho auch mehr als das Kürzel aussagt)

if(this->isEmpty)

cu André

drakon

Da ich noch nicht die Ehre hatte mit vielen Leuten an einem grossen Projekt zu arbeiten kann ich nichts dazu sagen, wie das sonst ist.

Aber im Grossen und Ganzen kann ich dir schon zustimmen, dass es auch Nachteile hat. Persönlich finde ich, dass man sich bei einem (grossen Projekt) mit den Leuten abspricht und abmacht, was gilt und wie man es macht. Gibt ja kein "richtig" oder "falsch", sondern nur, WIE man es macht.

Wenn man allerdings alleine ist, würde ich empfehlen es so zu machen, wie man es am besten versteht und es einem auch was bringt. Ich habe das mit dem m_ noch sehr gerne. Und auch die kurze Präfixe, die mir Anzeigen, was es für ein Typ ist.
Aber ich finde, dass ein guter, sprechender Name dennoch sehr wichtig ist. Da dann der Code logischer/einfacher zu lesen wird.

Badestrand

Kleiner Zusatz: Man muss sich ja auch nicht entscheiden für oder gegen Ungarische Notation, man darf ja durchaus auch nur Teile davon verwenden (ich z.B. nutze 'm_' für Membervariablen, Typkürzel aber nicht, also etwa 'm_some_var') oder ein eigenes System einsetzen oder oder oder.

drakon

Badestrand schrieb:

Kleiner Zusatz: Man muss sich ja auch nicht entscheiden für oder gegen Ungarische Notation, man darf ja durchaus auch nur Teile davon verwenden (ich z.B. nutze 'm_' für Membervariablen, Typkürzel aber nicht, also etwa 'm_some_var') oder ein eigenes System einsetzen oder oder oder.

Absolut. Ich glaube die meisten benutzen eh irgend ein Mischmasch.

Wie sieht den das aus, wenn du etwas grösseres Codest, ohne (zumindest Ansatzweise) irgendwelche Kürzel, wird das doch ziemlich umständlich. Oder hast du da eine "enge" Namensgebung?

asc

drakon schrieb:

Ich habe das mit dem m_ noch sehr gerne. Und auch die kurze Präfixe, die mir Anzeigen, was es für ein Typ ist.

Ich habe persönlich festgestellt das (zumindest bei mir ist das so) man spätestens sobald ein Projekt größer wird, auch häufiger zu Templates greift (Mit dem beschriebenen Typenproblem).

Ich kann dich aber auch in einigen Punkten verstehen: Sofern man noch mit einer kleinen Anzahl an Typen arbeitet kann auch die UN noch übersichtlich wirken (wenn ich sehr in Stress bin ertappe ich mich auch manchmal wie ich in diesen Schreibstil verfallen will, wobei ich ihn selbst schon früh auf ein absolutes Minimum wie das von dir geschriebene m_ und p reduziert hatte bevor ich mich gänzlich davon abgewendet habe).

cu André

Badestrand

drakon schrieb:

Wie sieht den das aus, wenn du etwas grösseres Codest, ohne (zumindest Ansatzweise) irgendwelche Kürzel, wird das doch ziemlich umständlich. Oder hast du da eine "enge" Namensgebung?

Meine Variablen-Namen sind eigentlich alle klein geschrieben und die Wörter halt durch Unterstriche getrennt. Der Typ der meisten Variablen ergibt sich oft, dem englischen sei Dank endet der Plural ja auf 's' und wenn ich sowas wie 'lines' oder 'tokens' oder so sehe, dürfte das ein vector<sonstwas> sein, den direkten Typen sehe ich dabei nicht, macht aber selten was; wenn die Variable als Funktions-Parameter übergeben wurde oder in der Funktion deklariert wurde, ist der Typ ja noch auf dem Bildschirm, ansonsten muss ich halt auf den Tool-Tip warten

Ich benutze glaubich sowieso nur wenige Typen von Typen für Variablen, bools, Zahlenvariablen, Strings, Container (vector,map am häufigsten), paar Std-Sachen (für Dateien und bissl anderes) und eigene Klassen/Strukturen. Container-Variablen-Namen sind halt im Plural, Klassen-/Strukturen-Variablen haben oft einen direkten Bezug zum Klassennamen (z.B. Variable 'pos' für Klasse 'Position' oder Variable 'srcfile' für Typ 'std::ifstream' oder 'mainwnd' für Klasse Window). In for-Schleifen haben Zahlenvariablen meist kurze Bezeichner wie 'i' oder 'j', ansonsten meist irgendwas mit 'xyz_nr' oder 'xyz_count'. Boolean-Variablen haben ihren 'Sinn' bei mir oft auch im Namen, da erkennt man das ganz gut, z.B. 'is_invalid' oder 'bla_found'.

Naja, ist wahrscheinlich auch eine Art Notation, aber es kommen halt öfters Informationen durch den Namen rüber, alles lässt sich aber nicht abdecken.. Allerdings wechselt mein Stil auch immer so alle 2-3 Jahre, je nachdem was mir am besten gefällt Ich denke, das ganz muss einfach nur lesbar sein, dann erfüllt die Notation ihren Zweck. Und ich find's auch schön, dass der Markt an verschiedenen Schreibweisen so groß ist, wäre langweilig sonst