Underscore erlaubt?

Hi, ich habe bezüglich des Underscores unterschiedliche Meinungen gehört und möchte jetzt Gewissheit haben. Sind Variablennamen (camelCase) in Kombination mit einem führenden Underscore nun erlaubt oder doch reserviert?
z.B.

int _myInt;
double _myDouble;

Der Underscore benutzt man z.B bei Systemprogrammierung, einfach so zu benutzen ist schlechter Stil!

Reservierte Symbole sind wie folgt:

1. Alles, was zwei Unterstriche in Folge beinhaltet
2. Alles, was mit einem Unterstrich gefolgt von einem Großbuchstaben beginnt
3. Im globalen Namensraum zusätzlich alles, was mit einem Unterstrich beginnt.

Also:

int fo__o; // Verboten.
int _Foo; // Verboten.
int _foo; // Verboten.

class Foo {
  int fo__o; // Verboten.
  int _Foo; // Verboten.
  int _foo; // Erlaubt.
};

int main() {
  int fo__o; // Verboten.
  int _Foo; // Verboten.
  inf _foo; // Erlaubt.
}

Aufgrund der etwas verworrenen Regelung ist es im allgemeinen als guter Stil anerkannt, Unterstriche am Anfang eines Variablennamens generell zu vermeiden.

@seldon
Danke für die Beispiele. Werde dann die private Membervariablen meiner Klassen mit einem Underscore versehen um Namenskonflikten wie array, property, template usw. zu vermeiden.
Noch eine Frage in diesem Zusammenhang. Wird in folgender Funktion eigentlich eine Dereferenzierung (hoffe richtiger Begriff) durchgeführt, oder optimiert der Compiler dies?

void MyClass::Count(int count)
{
    this->count = count;
}

Wäre also folgendes schneller?

void MyClass::Count(int count)
{
    _count = count;
}

cooky451

_underScore schrieb:

...

Ja, das ist eine Dereferenzierung. Beide Methoden sind gleich schnell. Was der Compiler optimiert, hängt damit nicht zusammen.

Wie seldon schon schrieb, ist es recht unüblich Variablennamen mit einem Unterstrich beginnen zu lassen, auch wenn es prinzipiell nicht "verboten" ist.

Du könntest z.B. am Ende einen Unterstrich machen (data_) oder ein "m" davor machen (m_data, mData, ..).

rüdiger

Siehe FAQ: http://www.c-plusplus.net/forum/39461

Ethon

1. Alles, was zwei Unterstriche in Folge beinhaltet

Dabei ist aber auch recht verbreiteter Stil, solche zu nutzen, wenn man C Interfaces für C++ Klassen schreibt.

Also zb

Server__Receive

statt

Server::Receive

shadow

Underscore schrieb:

Der Underscore benutzt man z.B bei Systemprogrammierung, einfach so zu benutzen ist schlechter Stil!

Wohl eher nicht. Viele nutzen diese Möglichkeit um bei verschachtelter Vererbung die eigenen Member sofort sehen zu können (Intelli Sense). Notationen finde ich lustig, sie schreiben jedem was vor was man wie tun sollte. Das ist eben das, was entgegen das Grundprinzip der eigenen intelektuellen Entwicklung spricht. Aber jedem das Seine

cooky451 schrieb:

Du könntest z.B. am Ende einen Unterstrich machen (data_) oder ein "m" davor machen (m_data, mData, ..).

Das "m_" anstatt "_" wäre eine Überlegung wert, allerdings kann ich die Ungarische Notation mitlerweile nicht mehr sehen. Der Underscore nach dem Variablenname wäre auch mein Favourit gewesen, wenn damit Pointer nicht so hässlich aussehen würden.

Nexus

Ethon schrieb:

Dabei ist aber auch recht verbreiteter Stil, solche zu nutzen, wenn man C Interfaces für C++ Klassen schreibt.

Also zb
Server__Receive

Warum nicht Server_Receive ? Doppel-Unterstriche sind eigentlich nur nötig, wenn die Bezeichner selbst schon Unterstriche haben. Aber dann wirds eh hässlich.

_underScore schrieb:

Das "m_" anstatt "_" wäre eine Überlegung wert, allerdings kann ich die Ungarische Notation mitlerweile nicht mehr sehen. Der Underscore nach dem Variablenname wäre auch mein Favourit gewesen, wenn damit Pointer nicht so hässlich aussehen würden.

Vorgestelltes "m" würde ich nicht als UN im klassischen Sinne sehen, weil es keine Typen bezeichnet. Damit fallen auch viele der UN-Probleme weg. Und überhaupt läuft "_" und "m" so ziemlich aufs selbe heraus, ausser dass man den nachgestellten Unterstrich leichter vergisst/übersieht.

Ethon schrieb:

Dabei ist aber auch recht verbreiteter Stil, solche zu nutzen, wenn man C Interfaces für C++ Klassen schreibt.

Also zb
Server__Receive
statt
Server::Receive

Ich glaube nicht, so etwas schon mal gesehen zu haben. Es wäre auch in C schlicht falsch; da gilt die selbe Vorschrift.

@shadow: Ich habe mir sagen lassen, dass man neben der intellektuellen Entwicklung als Programmierer auch Dinge auf die Reihe kriegen muss. Dabei sind Konventionen, an die sich jeder im Team zu halten hat, mitunter sehr hilfreich. Außerdem bewegt man sich als Programmierer nicht im Bereich der Kunst, wo größtmögliche Originalität gefragt ist; im Gegenteil ist es sinnvoll, sich der Erfahrungswerte derer, die vor einem gekommen sind, zu bedienen. Man steht, frei nach Newton, auf den Schultern von Giganten (bzw. auf den Schultern von Leuten, die auf den Schultern anderer Leute stehen).

Allerdings ist die Wahl, ob man jetzt m_ vor oder _ hinter den Namen einer Member-Variable schreibt, in diesem Zusammenhang von eher geringer Bedeutung. Gegen _ als Präfix würde ich mich verwahren, weil man auf die Art immer nur einen Moment der Flüchtigkeit von fehlerhaftem Code entfernt ist und wirklich kein Grund besteht, sich diese Problematik (egal, für wie gravierend man sie hält) einzuhandeln.

Was Intellisense angeht, so hat es sich für mich als nicht zuverlässig genug herausgestellt. Ich kriege mit MSVC 2008 teilweise immer noch Klassen vorgeschlagen, die es seit Monaten nicht mehr gibt. Wenn es aber brauchbar funktionierte, dann könnte man erstens mit einem Druck auf die m-Taste das Problem lösen und zweitens hätte ich größeres Interesse daran, das öffentliche Interface zuerst zu sehen, nicht die Member-Variablen. Es könnte allerdings ein Argument für die Kennzeichnung durch Präfixe darstellen.