Der _
-
der underscore ist hinten, da es sich besser läst
Passt doch zum aktuellen C++-Standard und dem diesbezüglichen Ausweichmanöver von Herb Sutter.
Konsequent wäre nun folgende Weiterentwicklung:
m_blaBla => _blaBla => blaBla_ => blaBla_m
:D:D:D:D
-
der _ ist doch fürn ***
-
Aber echt. Ich bin mal gespannt, wann es die Leute endlich checken, einfach nur "blaBla" zu schreiben.
-
Meiner meinung nach sollte der _ verboten werden. Ich kann das wirklich nicht haben, wenn_jede_funktion so viele unterstriche hat. Wir sind doch nicht bei PHP wo man dann mysql_real_real_real_escape_this_time_really_real eingeben darf.
-
princess schrieb:
also ich hab mir heut ma das style guide von der uni reingezogen und "guter/sauberer/ code sieht bei membern so aus:
Aber nur laut deiner Uni. Es gibt hier mehrere Geschmäcker, ich lehne z.B. jegliche Unterstriche in Variablennamen ab und ergänze Membervariablen auch nicht um irgendwelche Kürzel etc. (Wenn man die Unterscheidung braucht gibt es immer noch this->).
Dies ist aber auch nur eine von vielen Meinungen.
-
Wenn man die Unterscheidung braucht gibt es immer noch this->
Das ist ja wohl der letzte Ausweg.
this->blaBla
-
Erhard Henkes schrieb:
class Complex { public: Complex( double real, double imaginary = 0 ) : _real(real), _imaginary(imaginary) {}; void operator+ ( Complex other ) { _real = _real + other._real; _imaginary = _imaginary + other._imaginary; } void operator<<( ostream os ) { os << "(" << _real << "," << _imaginary << ")"; } //...In den MFC wurde m_BlaBla verwendet. Herb Sutter hat einfach das m (für "member") entfallen lassen.
Das macht echt Sinn
Ansatt es _logischerweise_ so zu machen:class Complex { public: Complex( double _real, double _imaginary = 0 ) : real(_real), imaginary(_imaginary) {}; void operator+ ( Complex _other ) { real = real + _other.real; imaginary = imaginary + _other.imaginary; } void operator<<( ostream _os ) { _os << "(" << real << "," << imaginary << ")"; } //...In dieser Variante muss man das "_" naemlich wesentlich weniger mitschreiben.
-
--
-
Da das alles nur Style-Zeug ist brauch ich das vorerst nicht zu beachten.
Zum Glueck gibt es immer solche kleinen Details, über die sich Leute streiten können.
Und zum Glueck habe unsinnige Streitereien auch einen Sinn.
Ihr finanziert das Forum damit^^
-
Quellcode schrieb:
Da das alles nur Style-Zeug ist brauch ich das vorerst nicht zu beachten.
Fang lieber gleich damit an, was man sich mal angewöhnt hat gewöhnt man sich schwer wieder ab. Und "stillos" zu programmieren ist eine Sache die man sich IMO gleich garnicht angewöhnen sollte.
-
was genau ist der sinn von sowas?
m_foo ist furchtbar weil es intellisense erschwert
foo ebenso nur ist es kürzer und daher besser
foo ist ok, weil es intellisense nicht zerstört aber ich sehe den sinn nicht.was bringt mir eine kennzeichnung der member variablen? das klingt so sehr nach polnische notation und das klingt furchtbar.
folgender code funktioniert übrigens:
explicit Complex( double real, double imaginary = 0 ) : real(real), imaginary(imaginary) {}PS:
in java schafft man es ja auch ohne m_ auszukommen...
-
FULL ACK Shade
MfG SideWinder
-
Complex( double real, double imaginary = 0 ) : real(real), imaginary(imaginary) {} public: double real() { return real; } void real(double real) { this.real = real; } double imaginary() { return imaginary; } void imaginary(double imaginary) { this.imaginary = imaginary; } private: double real; double imaginary;Und nun?
-
Zeus schrieb:
Und nun?
get/set verwenden?
-
Shade Of Mine schrieb:
was bringt mir eine kennzeichnung der member variablen? das klingt so sehr nach polnische notation und das klingt furchtbar.
Dem kann ich mich auch nur anschließen. Meiner Erfahrung nach führt dies auch zu ein leicher lesbaren Code - aber Geschmäcker sind verschieden (Macht den Stil in eurer Firma/Projekt aus).
cu André
-
Shade Of Mine schrieb:
Zeus schrieb:
Und nun?
get/set verwenden?
Die sind doch da?
Wieso soll ich Membervariable Kennzeichnen?
Wieso soll ich Getter/Setter Kennzeichenen?Das sind Fragen, die man nicht im Einzelen beantworten, sondern im Ganzen.
-
Shade Of Mine schrieb:
Zeus schrieb:
Und nun?
get/set verwenden?
Dann ist das, das gleiche Argument wie "für _".
@all!
Übrigens, wir benutzen in unseren Java-Projekten (ja!) für Member-Variablen einen vorangestellten Unterstrich!!! Hier zu pauschalisieren, das alle Java-Projekte keine Unterstriche verwenden, ist ja auch genial.
-
Gröhler schrieb:
@all!
Übrigens, wir benutzen in unseren Java-Projekten (ja!) für Member-Variablen einen vorangestellten Unterstrich!!! Hier zu pauschalisieren, das alle Java-Projekte keine Unterstriche verwenden, ist ja auch genial.Damit seid ihr aber sicher die Ausnahme die die Regel bestätigt.
Zeus schrieb:
Wieso soll ich Getter/Setter Kennzeichenen?
Methodennamen sind Verben und sollen eine Tätigkeit darstellen. In diesem Fall "bekomme variable" also "getVar()" bzw. "getvar()" oder wie auch immer. Während Size den Klassentyp darstellt und size eine Instanz davon.
MfG SideWinder
-
natürlich kann man _ verwenden um hausgemachte probleme zu beseitigen - aber worum es mir geht ist, eine prinzipielle verwendung von _ oder m_
denn viele verwenden das, genauso wie C oder T als ersten buchstaben im klassen namen - "weil man es eben so macht".wenn man namenskonflikte hat, muss man sie lösen.
ich verwende auch _ wenn ich diese komische c++ library konvention einhalten muss, weil es nicht anders geht. aber dann markiert der _ ja keine membervariable, sondern er umgeht namenskonflikte (das ist ein großer unterschied).
-
Außerdem macht ein führender Unterstrich meistens das IntelliSense schwächer, da ich zumindest zwei Buchstaben schreiben muss (_ + Anfangsbuchstabe) um dann mit CTRL+SPACE zu erweitern.
MfG SideWinder
