Whitespaces

someFunction ( someOtherFunction ( someArguments, someMoreArguments ), moreFunctions ( functionForArgument(), yep( arguments ) ), yep ( someOtherfunction() ) );

Ist das wirklich so hässlich? Oder zu kritisch wegen line-length?

Man macht das wohl nicht, aber ich finde das gegenüber

someFunction(someOtherFunction(someArguments,someMoreArguments),moreFunctions(functionForArgument(),yep(arguments)),yep(someOtherfunction()));

irgendwie lesbarer.

Ich muss mich schon immer dazu zwingen die Leerzeichen nicht zu machen, weil das kein Mensch außer mir macht.

Nun gut, auf der Arbeit löscht das die IDE mit den saving-actions eh wieder weg

Shade Of Mine

Du könntest es ja mal mit dem Zeilenschalter probieren. Der soll
ganz
praktisch
sein,
hab
ich
gehört.

LordJaxom

In Java finde ich es hässlich.
In C++ mache ich es selbst.

TyRoXx

._. schrieb:

someFunction ( someOtherFunction ( someArguments, someMoreArguments ), moreFunctions ( functionForArgument(), yep( arguments ) ), yep ( someOtherfunction() ) );

Ist das wirklich so hässlich?

Es ist extrem hässlich, für einen geübten Programmierer schwerer lesbar und wirkt wie von einem Anfänger, der die Operatoren noch in einem Buch nachschlagen muss.

._. schrieb:

someFunction(someOtherFunction(someArguments,someMoreArguments),moreFunctions(functionForArgument(),yep(arguments)),yep(someOtherfunction()));

Da fehlen einfach die Leerzeichen an einigen Stellen.

someFunction(someOtherFunction(someArguments, someMoreArguments), moreFunctions(functionForArgument(), yep(arguments)), yep(someOtherfunction()));

Das sind akzeptable Schreibweisen:

someFunction(
	someOtherFunction(someArguments, someMoreArguments),
	moreFunctions(functionForArgument(), yep(arguments)),
	yep(someOtherfunction())
);

auto a = someOtherFunction(someArguments, someMoreArguments);
auto b = moreFunctions(functionForArgument(), yep(arguments));
auto c = yep(someOtherfunction());
someFunction(a, b, c);

EOP

TyRoXx schrieb:

Das sind akzeptable Schreibweisen:

someFunction(
	someOtherFunction(someArguments, someMoreArguments),
	moreFunctions(functionForArgument(), yep(arguments)),
	yep(someOtherfunction())
);

Das ist ok. Kann man mit einem Blick erfassen.

Shade Of Mine schrieb:

Du könntest es ja mal mit dem Zeilenschalter probieren

ist das oestereichisch fuer \r oder \n?
:p

hustbaer

@._.
Was Whitespaces angeht gibt's ein paar Sachen die ziemlich einheitlich gehandhabt werden, und daher fast schon als de facto Standard anzusehen sind.
Z.B. dass man nach Kommas oder Strichpunkten ein Leerzeichen macht.
Zwischen Keywords und öffnender Klammer kommt auch ein Leerzeichen.
Vor und nach Klammern ansonsten nicht.

Im Endeffekt sieht dein Beispiel dann so aus wie TyRoXx es geschrieben hat.

Das eigentliche Problem ist aber dass das Statement u.U. viel zu gross ist.

Kommt natürlich auch drauf an was "someFunction", "someOtherFunction" etc. wirklich für Namen sind.
Wenn es sehr sprechende Namen von Funktionen sind die man nur für einen Zweck verwenden kann (z.B. fileInfo.GetFileName() - da kommt halt immer ein Filename zurück), dann kann man schonmal tiefer verschachteln.

Je weniger sprechend der Name und je vielseitiger eine Funktion eingesetzt werden kann, desto eher wird es problematisch. Also z.B. bei mathematischen Funktionen ist oft nicht auf den ersten Blick klar wofür sie verwendet werden. Speziell wenn man ein Programm noch nicht gut kennt und in der speziellen Domäne kein Experte ist.
Wenn da dann sqrt(some expression) oder atan(some expression) steht ist mir u.U. nicht auf den ersten Blick klar was da eigentlich ausgerechnet wird.

Und genau dann, wenn man alleine anhand der verwendeten Bezeichner (Funktionsnamen, Variablennamen etc.), nicht mehr "auf einen Blick" (=innerhalb weniger Sekunden) erkennen kann was da abgeht ... genau dann ist es zu gross und sollte weiter aufgebrochen werden.
Und zwar auch so wie es TyRoXx gezeigt hat, nur natürlich mit besseren Bezeichnern als a, b und c.
Also

auto someClearAndEasyToUnderstandIdentifier = someOtherFunction(someArguments, someMoreArguments);
auto anotherEasyToUnderstandThing = moreFunctions(functionForArgument(), yep(arguments));
auto aGoodName = yep(someOtherfunction());
someFunction(someClearAndEasyToUnderstandIdentifier, anotherEasyToUnderstandThing, aGoodName);

Wenn du das machst, dann darfst du von mir aus auch deine Whitespaces "falsch" setzen. Dabei käme mir zwar immer noch das Kotzen wenn ich es lesen müsste, aber zumindest könnte ich trotz Kotzerei recht schnell erfassen was der Code macht.

tntnet

hustbaer schrieb:

@._.
Was Whitespaces angeht gibt's ein paar Sachen die ziemlich einheitlich gehandhabt werden, und daher fast schon als de facto Standard anzusehen sind.
Z.B. dass man nach Kommas oder Strichpunkten ein Leerzeichen macht.
Zwischen Keywords und öffnender Klammer kommt auch ein Leerzeichen.
Vor und nach Klammern ansonsten nicht.

Das ist kein de facto Standard. Dazu gibt es sogar einen Standard. Das lernt man im Schreibmaschinenkurs (wisst ihr noch, was eine Schreibmaschine ist?).

Ansonsten hat ja TyRoXx bereits gezeigt, wie es richtig zu formatieren ist. Es muss halt leicht zu erfassen sein. Ich würde es sogar reduzieren von wenigen Sekunden auf Bruchteile von Sekunden. Wenn ich mir überlege, Code zu lesen, bei dem ich bei jedem Statement mehr als eine Sekunde benötige, da rollen sich bei mir die Zähennägel auf .

Mit den auto Variablen muss man aufpassen, dass man nicht versehentlich eine überflüssige Kopie macht. Auf der anderen Seite können die Namen solcher temporären Variable zusätzliche Informationen zum Verständnis des Codes geben.

hustbaer

tntnet schrieb:

Das ist kein de facto Standard. Dazu gibt es sogar einen Standard.

Echt? Wie heisst der? Und wo steht geschrieben dass es der Standard ist an den man sich zu halten hat.

tntnet schrieb:

Auf der anderen Seite können die Namen solcher temporären Variable zusätzliche Informationen zum Verständnis des Codes geben.

Ja. Darum ging es mir. Genau das hab ich ja geschrieben.

tntnet

hustbaer schrieb:

tntnet schrieb:

Das ist kein de facto Standard. Dazu gibt es sogar einen Standard.

Echt? Wie heisst der? Und wo steht geschrieben dass es der Standard ist an den man sich zu halten hat.

DIN 5008

tntnet schrieb:

hustbaer schrieb:

tntnet schrieb:

Das ist kein de facto Standard. Dazu gibt es sogar einen Standard.

Echt? Wie heisst der? Und wo steht geschrieben dass es der Standard ist an den man sich zu halten hat.

DIN 5008

und wieso sollte man jetzt so einen Standard fuer das Formatieren von Briefen auf Quelltext uebertragen?

Es gibt auch richtige Programmierstandards. Z.B. http://www.gnu.org/prep/standards/standards.html#Formatting
(der einzig wahre fuer C/++, und das ist natuerlich ueberhaupt keine persoenliche Meinung sondern de facto von jedem akzeptiert )