Stilfrage: T& a oder T &a

Marthog

Ich habe mir die Frage auch schon gestellt und es gibt bei allem irgendwelchen Probleme.
Letztendlich bin ich aber zu T& a übergegangen, weil das Referenzzeichen ja zum Typ gehört und nicht zum Namen.

Generell würde ich das aber als Geschmacksfrage beschreiben.

Ich bin mittlerweile dazu übergegangen, immer T&/T* zu verwenden, wenn nur eine Variable diesen Typ bekommt (also auch in Parametern, die sind meistens nicht auf einer einzelnen Zeile).

volkard schrieb:

Ind C++ definiert man eine Variable eigentlich erst, wenn man sie sinnvoll initialisieren kann

Es gibt die genannte Ausnahme, wenn man die Membervariablen einer Struktur deklariert:

private:
  const char *token_begin, *token_end, *end;

Dann mache ich den Stern zum Namen. Allerdings immer nur ein Typ pro Zeile, nie Pointer und Nicht-Pointer gemischt.

Btw: Ich ziehe "T const&" der Schreibweise "const T&" vor, weil T ist eine const-referenz und T const& ist besser zu lesen (wichtiges zuerst), schreiben und aussprechen.

Shade Of Mine

five star programmer schrieb:

Es gibt die genannte Ausnahme, wenn man die Membervariablen einer Struktur deklariert:
private:
  const char *token_begin, *token_end, *end;
Dann mache ich den Stern zum Namen. Allerdings immer nur ein Typ pro Zeile, nie Pointer und Nicht-Pointer gemischt.

Ich mache eine Variable pro Zeile - ist viel besser lesbar. und wenn man einen kommentar zu einer variablen packen will ists auch einfacher dann. oder die commits bei code änderungen an der klasse - ich muss keine zeile mit 10 variablen anpassen und dann funktionieren die blames wieder nicht gut genug. ne ne. 1 zeile pro variable ist besser.

Btw: Ich ziehe "T const&" der Schreibweise "const T&" vor, weil T ist eine const-referenz und T const& ist besser zu lesen (wichtiges zuerst), schreiben und aussprechen.

dem stimme ich hingegen voll zu.

hustbaer

Tomahawk schrieb:

private:
  const char* m_token_begin;
  const char* m_token_end;
  const char* m_end;

+1

Nur dass du das const auf der falschen Seite von char stehen hast

TyRoXx

Wenn man mal den Namen weglässt, sieht eine der beiden Varianten unnötig gequetscht aus:

void (int&, std::string*)

void (int &, std::string *)

Gerade als Template-Argument geht ein kleines & oder ein * unter, wenn kein Leerzeichen davor steht.
Bei g finde ich die linke Seite durch den langen Typ sehr unübersichtlich. Für das Sternchen am Ende des Typs muss ich zweimal hinsehen. Wenn es jedoch rechts vom Leerzeichen direkt am Namen steht, sehe ich es sofort.

void g(std::vector<int*>::iterator* it);

void g(std::vector<int *>::iterator *it);

theliquidwave

Gutes Argument, TyRoXx. Stimme dir zu. War mir vorher noch gar nicht so bewusst, das mit dem Auffallen.

*rant*

T *foo

Begründung für mich:

T* foo, bar;
static_assert(std::is_same<decltype(foo), decltype(bar)>::value, "Nope");

*, &, && (und bei C++/CLI ^ und gehören zum Namen, nicht zum Typen.

camper

TyRoXx schrieb:

Wenn man mal den Namen weglässt, sieht eine der beiden Varianten unnötig gequetscht aus:
void (int&, std::string*)

void (int &, std::string *)
Gerade als Template-Argument geht ein kleines & oder ein * unter, wenn kein Leerzeichen davor steht.
Bei g finde ich die linke Seite durch den langen Typ sehr unübersichtlich. Für das Sternchen am Ende des Typs muss ich zweimal hinsehen. Wenn es jedoch rechts vom Leerzeichen direkt am Namen steht, sehe ich es sofort.
void g(std::vector<int*>::iterator* it);

void g(std::vector<int *>::iterator *it);

verstehe das Argument nicht

void g(std::vector<int *>::iterator *it)
//                   ^ das ist das Templateargument, ein Name folgt nicht

void g(std::vector<int *>::iterator *it)
//                                   ^  das ist ein Name, aber der Teil davor kein Templateargument

/rant/ schrieb:

T *foo
Begründung für mich:
T* foo, bar;
static_assert(std::is_same<decltype(foo), decltype(bar)>::value, "Nope");
*, &, && (und bei C++/CLI ^ und gehören zum Namen, nicht zum Typen.

petitio principii

...Und natürlich gehört const vor den Typ (wo möglich), denn das ist die natürliche Reihenfolge in der Sprache (English), aus der diese Wörter stammen.

Nathan

Mit const stimm ich camper zu. Blöd nur, dass das bei Pointern ungedrejt ist.
Bei mir säh ein Pointer so aus:
const * const T foo;
Heißt das was man liest: konstanter Pointer auf konstantes T.
Was T& angeht, hab ich mich noch nicht entschieden, verwend es mal so, mal so.

Caligulaminus

Typdeklarationen liest man von rechts nach links (und von innen nach außen).

T const * const foo;

foo ist ein konstanter Zeiger auf ein konstantes T.

Deshalb schreibe ich es auch so.

dot

Nathan schrieb:

const * const T foo;

Das ist kein gültiges C++...

Caligulaminus

Nathan schrieb:

Bei mir säh ein Pointer so aus:

Die Aussage war doch klar:
Wenn es nach Nathan ginge, wär's gültig.

Nathan

Danke, dot, aber ich glaub ich weiß wie man Pointer deklariert.
Man schreibt dazu ein & hinter den Typen.

mein stil:

T const& d;
T& d;
const T d;

für mich gehören referenzen usw einfach zum typen (mehrere definitionen in einer zeile sind sowieso das unleserlichste was ich mir vorstellen kann, mach ich nie).

camper

Caligulaminus schrieb:

Typdeklarationen liest man von rechts nach links (und von innen nach außen).
T const * const foo;
foo ist ein konstanter Zeiger auf ein konstantes T.

Deshalb schreibe ich es auch so.

Das zäumt das Pferd von hinten auf. rechts-nach-links ist lediglich, wie die Deklaration interpretiert wird (auch nur als Faustregel, weil es uns so schwer fällt echt rekursiv zu denken). Gelesen wird nat. trotzdem von links nach rechts (schließlich muss Anfang und Ende erfasst werden), denn der Lesefluss bleibt ja weiterhin rechts-nach-links, oben-nach-unten. Ich kann nicht nachvollziehen, dass diese Umkehrung als natürlich oder einfach empfunden wird. Gewöhnen kann man sich selbstverständlich daran.
Eine Variablendefinition benötigt einen 1. Typ, 2. einen Bezeichner, und 3. einen Initialisierer. Deklaratoren an den Namen anzuflanschen, vermischt 1. und 2. und direkte Initialisierung mittels () oder {} hebt auch noch die Trennung zu 3. auf - was zu zusätzlicher mentaler Arbeit führt, weil diese Teil nicht mehr klar optisch getrennt sind. Von der Tatsache, dass uns die Syntax Fälle aufzwingt, in denen diese Vermischung nicht (einfach) vermieden werden kann, führt allerdings keine Schlussregel, die bestimmt, dass dann auch in allen anderen Fällen so vorgegangen werden sollte.

Mehrfachdefinitionen in einer Zeile sind $\sqrt{\forall evil}$

Antwort an TE: mach, was du willst (ausser Bekehrungsversuchen), nur einheitlich.

Caligulaminus

camper schrieb:

Ich kann nicht nachvollziehen, dass diese Umkehrung als natürlich oder einfach empfunden wird.

C++ ist nicht natürlich, ist technisch. Technik ist künstlich - Kunst.
Ich lese Typdeklarationen von rechts nach links. Das mußte ich mir angewöhnen. Daß ich es akzeptiert und verinnerlicht habe, hat mein Programmierer-Dasein spürbar vereinfacht.

camper schrieb:

Mehrfachdefinitionen in einer Zeile sind $\sqrt{\forall evil}$

Mehrfachdeklarationen in einer Zeile (Funktionsparameter) sind quasi unvermeidbar. Wenn es logisch passt finde ich das sogar empfehlenswert, z.B. iter begin, end;

funkyunicoder schrieb:

camper schrieb:

Mehrfachdefinitionen in einer Zeile sind $\sqrt{\forall evil}$

Mehrfachdeklarationen in einer Zeile (Funktionsparameter) sind quasi unvermeidbar. Wenn es logisch passt finde ich das sogar empfehlenswert, z.B. iter begin, end;

mehrfachdeklarationen in einer zeile bei funktionsargumenten und bei der definition von variablen haben nicht die selbe syntax...

int* a, * b;
void f(int* a, int* b) {}

Th69

Hallo camper,

camper schrieb:

denn der Lesefluss bleibt ja weiterhin rechts-nach-links, oben-nach-unten.

Editiere dies mal, denn du meinst ja "links-nach-rechts"

Bashar

not smart schrieb:

für mich gehören referenzen usw einfach zum typen (mehrere definitionen in einer zeile sind sowieso das unleserlichste was ich mir vorstellen kann, mach ich nie).

Alles außer dem Bezeichner (und dem Initialisierer) gehört in einer Deklaration zum Typ. Insbesondere gehören dazu auch Elemente, die rechts vom Bezeichner stehen, z.B. Array-Klammern und Parameterlisten.

Stilfrage: T&amp; a oder T &amp;a

Stilfrage: T& a oder T &a