Ich häng an einen Unterstrich ans Ende.
Allerdings nicht um Membervariablen als solche zu kennzeichnen, sondern aus ganz simplen Ambiguitätsgründen:
Ich mag die Art wie die STL (Getter-)Funktionen nennt, d.h. size() anstatt getSize(), empty() anstatt isEmpty(), etc.. Die aktuelle Größe wird nun in einer Membervariablen gespeichert, aber wie nenn ich die? size geht ja nicht, also muss die gekennzeichnet werden. Und ein Unterstrich am Ende find ich am wenigsten störend. Und aus Konsistenz schreib ich den dann bei allen Membervariablen.

Aus den Gruenden finde ich den Unterstrich am Ende am Besten. Allerdings finde ich die Schreibweise variable_->someFunction() und variable_.bla() sowas von haesslich, dass ich es bisher nie gemacht und Namenskollisionen auf andere Wege vermieden habe.

@oenone

oenone schrieb:

m_ als Präfix für Membervariablen ist genauso unnötig wie das C als Präfix für Klassen.

Falsch.
Bei Klassen erkannt man anhand des Kontext was ne Klasse ist und was nicht, ohne die ganze Funktion abgrasen zu müssen.

Parameter, lokale Variablen, globale Variablen und Membervariablen kann man aber nicht auseinanderhalten. Und die Info worum es sich dabei handelt ist schon wesentlich.
Also die Unterscheidung Parameter vs. lokale Variablen weniger. Aber die Unterscheidung dreier Klassen, nämlich

1. lokal (Parameter + lokale Variablen)
2. object-scope (Membervariablen)
3. global
   ist wichtig.

Und jetzt komm bloss nicht mit dem Argument dass man, wenn die Variable passend benannt ist, aus dem Namen schliessen kann was sie sein muss. Das funktioniert in der Praxis nicht.

Erstens gibt es viel zu viel dumme Programmierer die viel zu viel dumme Fehler machen, und zweitens will ich nicht denken müssen wenn mich grad bloss interessiert ob etwas "bleibende Auswirkungen" haben kann oder nicht. Oder wenn ich gucken will ob alle Stellen wo es nötig ist passend synchronisiert sind.

EDIT: wobei ich zugeben muss, dass CodeCompletion in Kombination mit Präfixen eine tolle Combo ist. (damit meine ich m_ . LPCTSTR DASDIAJHF ILNADJAIPJSFAF ist einfach nur evil)

Falsch.
[...]

Parameter, lokale Variablen, globale Variablen und Membervariablen kann man aber nicht auseinanderhalten. Und die Info worum es sich dabei handelt ist schon wesentlich.
Also die Unterscheidung Parameter vs. lokale Variablen weniger. Aber die Unterscheidung dreier Klassen, nämlich

1. lokal (Parameter + lokale Variablen)
2. object-scope (Membervariablen)
3. global
   ist wichtig.

Falsch. [Es folgt eine absolut formulierte Gegenargumentation.]

Globale Variablen soll man in C++ sowieso nicht verwenden. Wenn was global ist, dann als Scott-Meyer-Singleton (also in einer Funktion mit statischer Variable) gekapselt. Damit hat man seine spezielle Kenntzeichnung und Kategorie 3 fällt schonmal raus.

Funktionen sollen nur max. 7 Zeilen haben, selbst wenn das bei schlechtem Code ausnahmsweise mal 14 werden, sollte man Parameter+lokale Variablen im Kopf behalten können, wenn man den Code durchschaut. Also ist die Unterscheidung zwischen 1 und 2 aus dem Kontext klar und braucht keine Gedächtnisstütze.

Du unterscheidest noch, wie oben geschrieben, statische und nicht-statische Member. Da statische Member klar die Ausnahme darstellen, sollten nur diese gekenntzeichnet werden.

Funktionen sollen nur max. 7 Zeilen haben, selbst wenn das bei schlechtem Code ausnahmsweise mal 14 werden, sollte man Parameter+lokale Variablen im Kopf behalten können, wenn man den Code durchschaut.

Erstmal ist "max. 7 Zeilen" unpraktikabel. Ich weiss auch nicht wo du die Zahl her hast. Und selbst bei 7 Zeilen ist es zu anstrengend die wichtigen Stellen, nämlich welche wo auf Membervariablen zugegriffen wird, nach dem Ausschlussprinzip suchen zu müssen.

warum - in der Praixs gibt es viel saubereren, neuen, schlechten und fiesen Code
also braucht man Strategien um jeden Code über die Zeit verbessern zu können (oder ihn auf diesen Zustand vorzubereiten), dazu gehört z.B. auch das schrumpfen von Funktionen usw. - Software wächst immer organisch - egal wie idealistisch man selbst oder die Entwickler um einen herum sind (Zeitdruck, Unerfahrenheit, Menge an Projekten usw. ergeben das irgendwann automatisch - aber bitte nicht mit Faulheit/fehlendem Interesse verwechseln das ist immer scheisse)

die wenigsten dieser allgm. Tips gelten für Ich-mache-immer-alles-alleine und sonstige Anfänger-Kodierer - und die haben meistens auch keine Ahnung warum Sie irgendwelche dieser Tips anwenden oder nicht - es fehlt die Erfahrung

m_ member //unnötig
p_ parameter //unnötig
g_ globale //kommt eh nicht vor
s_ statics //beides

Gast3 schrieb:

warum - in der Praixs gibt es viel saubereren, neuen, schlechten und fiesen Code also braucht man Strategien um jeden Code über die Zeit verbessern zu können

Ich übersetze: "Ich schreibe viel schlechten Code und bin völlig ratlos. Deshalb suche ich Zuflucht in mystischen Ritualen."

Gast3 schrieb:

die wenigsten dieser allgm. Tips gelten für Ich-mache-immer-alles-alleine und sonstige Anfänger-Kodierer - und die haben meistens auch keine Ahnung warum Sie irgendwelche dieser Tips anwenden oder nicht - es fehlt die Erfahrung

Wichtiger Bestandteil: Alle, die nicht zu meiner Sekte gehören, sind lächerlich dumm und kommen ganz sicher in die Hölle.

Hängt natürlich davon ab, was man proggert und wo und mit was. Mit einer c++-ähnlichen Sprache, die Properties kann, ist m_ fein, damit die Properties die feinen Namen kriegen können. Bei viel GUI-Code kann man m_ oder p_ wählen (beide zusammen ist nicht nötig), um bei den vielen gettern/settern keine Kollissionen mehr zu haben. s_ kann ich mir nicht vorstellen. "g_game" wurde zu "theGame".

Finde ich 1000 mal übersichtlicher und intuitiver als mit Präfixen zu arbeiten. Vor allem wenn man irgendwelche Klassen mit mathematischen Gleichungen hat, bei denen das Präfix dann genauso lang wäre wie der Bezeichner selbst.

Blöd ists natürlich bei Mehrdeutigkeiten, aber da finde ich einen Unterstrich am Ende des Bezeichners noch als kleinstes Übel.

Also ich lass mir Sachen wie Parameter oder Member Variablen einfach von der IDE als solche highlighten. Parameter grau (bzw. orange wenn sie nicht benutzt werden) und Member Variablen dunkelrot, statics unterstrichen und virtual kursiv.

Welche IDE (und Add-Ons) nutzt du?

Ansonsten privat benutz ich Visual Studio 2013 (ohne Add-Ons), da kann man sich das auch alles seperat highlighten lassen bis auf virtuelle Methoden. Aber das Highlighting für virtual braucht man auch nicht wirklich mMn. Wichtig für mich ist gesondertes highlighting für Member, Parameter und statische Sachen. Und das funktioniert wunderbar in VS.

ich verdiene mein Geld primär und schon über 10 Jahre mit Refaktoring/Überarbeitung von größeren C/C++ Projekten - also ~400kLOC und ein paar Jahre und Entwickler auf dem Buckel - da sieht man einfach alles was falsch, böse und schlecht ist und Mannmonate an Überarbeitung bedürfen, die Strategien die man sich dabei angewöhnt sind eher pragmatischer Natur - funktionieren aber auch sehr gut bei der Grüne-Wiese Entwicklung

(m|p|s|)_ ist

1. sehr einfach zu parsen/generieren wenn man mal selbst Code-Veränderungstools braucht, nicht immer sind alle guten Tools verfüg- oder anwendbar

2. man kann das in jedem neuen Team relativ schneller erklären und so die Verbesserbarkeit des Kodes beschleunigen - Entwicklungen werden ja nicht gestoppt nur weil man etwas schöner macht

Erfahrene Entwickler adaptieren alles was hilft - unerfahrene argumentieren sehr viel, oder sagen sachen wie "das finde ich nicht schön"...

@volkard
ich verdiene mein Geld primär und schon über 10 Jahre mit Refaktoring/Überarbeitung von größeren C/C++ Projekten

Oh, ein Jungspund. Na, erwarte keine Widerrede mehr von mir, das hab ich oft genug gehabt.

Gast3 schrieb:

Erfahrene Entwickler adaptieren alles was hilft - unerfahrene argumentieren sehr viel, oder sagen sachen wie "das finde ich nicht schön"...

Haste UN loslassen können? Klar adaptierst Du alles, auch Wünschelruten, ich sage doch nichts anderes.

Erstmal ist "max. 7 Zeilen" unpraktikabel. Ich weiss auch nicht wo du die Zahl her hast.

Von Java. Gibt so ein Java Buch über "schönen" Code, und da fands der Autor ganz toll, dass er mal ein Projekt gesehen hat, wo jede Funktion nur 3-4 Zeilen hatte.
Finde ich völlig sinnlos. Natürlich sollte man nicht übertreiben und hunderte Zeilen in eine Funktion stecken. Aber wenn man eine Funktion in zig Hilfsfunktionen aufteilt, sieht man nicht was passiert und muss nur ständig zwischen Hilftsfunktionen hin und herspringen, ganz davon zu schweigen, dass man viele Parameter rumreichen muss.

happystudent schrieb:

Also ich lass mir Sachen wie Parameter oder Member Variablen einfach von der IDE als solche highlighten.

Das hilft schon mal, aber ich verlass mich nicht gern auf IDE Hilfsmittel. Wir können unseren Code online durchsuchen, da will ich auch sehen, was da verwendet wird. Und ich mach Code Dateien auch gern mal mit Notepad++ auf. Unter Linux hab ich früher sowieso nur vim benutzt, weil mich keine IDE überzeugt hatte.
Und ich bezweifle sehr stark, dass eine IDE bei umfangreichem, komplexem C++ Code die verschiedenen Variablentypen auseinanderhalten kann. Die Intellisense und Visual Assist steigen bei mir ständig aus.

Das hilft schon mal, aber ich verlass mich nicht gern auf IDE Hilfsmittel. Wir können unseren Code online durchsuchen, da will ich auch sehen, was da verwendet wird. Und ich mach Code Dateien auch gern mal mit Notepad++ auf. Unter Linux hab ich früher sowieso nur vim benutzt, weil mich keine IDE überzeugt hatte.

Naja, also ohne IDE kann (ich zumindest) nicht wirklich effizient arbeiten, man verliert ohne Auto-completion doch einfach sehr viel Zeit mit nachschauen (was ohne ein Jump-to-declaration auch noch ewig dauert). Ich überflieg auch mal online Code, aber wenn ich wirklich damit arbeiten will dann zieh ich mir den eh und bearbeite ihn in einer vernünftigen IDE...

Mechanics schrieb:

Und ich bezweifle sehr stark, dass eine IDE bei umfangreichem, komplexem C++ Code die verschiedenen Variablentypen auseinanderhalten kann. Die Intellisense und Visual Assist steigen bei mir ständig aus.

Also das mit den Variablentypen habe ich bis jetzt noch nicht als Problem erlebt... Es stimmt schon dass bei großen Projekten das Intellisense anfängt zu laggen (was auch ziemlich nerven kann), aber korrekt gehighlighted wurde bis jetzt eigentlich schon immer alles bei mir.

Also mein Qt-Creator hält die Variabeln schön farblich auseinander, kein Grund da mit Zusätzen zu arbeiten. Ich denke mal jede andere moderne IDE wird dies auch so tun.

Das ist ein gutes Argument, und so ziemlich das einzige was ich gelten lasse
Die IDE mit der wir arbeiten tut das nicht, von daher verwenden wir Prefixe.