Der _
-
also ich hab mir heut ma das style guide von der uni reingezogen und "guter/sauberer/ code sieht bei membern so aus:
class foobar{
public: //ctor
foobar();public: //methods
type const& get_st() const;
void fu();private:
// !!!
type foo_;
type bar_;
};der underscore ist hinten, da es sich besser läst
-
pedo bear schrieb:
17.4.3.1.2 Global names schrieb:
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
Ein Member ist ganz offensichtlich niemals Teil des globalen Namensraumes.
princess schrieb:
also ich hab mir heut ma das style guide von der uni reingezogen und "guter/sauberer/ code sieht bei membern so aus:
...
der underscore ist hinten, da es sich besser lästImmer dieser definitive Kram. Zweimal in Folge public: zu schreiben ist z.B. einfach Unfug.
Benutz' btw. mal cpp-Tags, dafür sind sie da.
-
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
