Lasst ihr beim einrücken 3 oder 4 Plätze frei

[Dravere]

sothis_ schrieb:

wo wir gerade dabei sind, wer setzt eigentlich runde klammern um den return wert?

Nur wenn ich klar hervorheben will, dass zuerst irgendwelche Operationen durchgeführt werden, vor dem return.
Meistens baue ich die Sache aber so, dass dieses klare hervorheben gar nicht nötig ist, denn das sieht meistens scheisse aus ^^

Nexus schrieb:

Wieso eigentlich das Semikolon am Schluss?

Mehr Angewohntheit als Sinn. Ich finde es irgendwie gut, wenn die Einzeiler schön abgeschlossen sind. Semikolon ist ja so ein wenig der absolute Stop der Zeile in C++

Nexus schrieb:

Aber wieso schreiben eigentlich soviele return 0; und die main() -Parameter auf, wenn man sie gar nicht benötigt?

Ich habe es so gelernt und mache es seither immer so. Ich dachte sogar, dass es offziell heisst, dass man es hinschreiben sollte, aber bin mir nicht mehr sicher. Aber wieso weglassen? So ist klar, dass 0 zurückgegeben wird, schliesslich kann man ja auch etwas anderes zurückgeben
Edit: Noch grad gesehen, die main Parameter schreib ich normalerweise nicht auf, das habe ich nur gemacht, damit man sieht, wie ich die Abstände bei Parametern setze

Hungarian? schrieb:

Wieso eigentlich das C im Klassennamen?

Weil ich es LIEBE das folgende schreiben zu können:

class CShip { /* ... */ };

// Irgendwo:
CShip Ship;

Grüssli

[Nexus]

Dravere schrieb:

Nexus schrieb:

Wieso eigentlich das Semikolon am Schluss?

Mehr Angewohntheit als Sinn. Ich finde es irgendwie gut, wenn die Einzeiler schön abgeschlossen sind. Semikolon ist ja so ein wenig der absolute Stop der Zeile in C++

Ok, durchaus verständlich. Aber konsequenterweise müsstest du dann nach jedem Block ein ; schreiben :p

Dravere schrieb:

Nexus schrieb:

Aber wieso schreiben eigentlich soviele return 0; und die main() -Parameter auf, wenn man sie gar nicht benötigt?

Ich habe es so gelernt und mache es seither immer so. Ich dachte sogar, dass es offziell heisst, dass man es hinschreiben sollte, aber bin mir nicht mehr sicher. Aber wieso weglassen? So ist klar, dass 0 zurückgegeben wird, schliesslich kann man ja auch etwas anderes zurückgeben

Ja, aber nicht, wenn das Ende von main() erreicht wird. Bezüglich des Standards bin ich mir selber nicht sicher, aber ich schreib eben nicht so gern überflüssigen Code
Das finde ich etwa gleich unnötig wie das void bei int Function(void); . Eben solche Überbleibsel von C.

[Shade Of Mine]

Dravere schrieb:

Weil ich es LIEBE das folgende schreiben zu können:

class CShip { /* ... */ };

// Irgendwo:
CShip Ship;

deshalb finde ich es zB toll dass meistens folgende Regeln eingehalten werden:

Klassen Namen sind CamelCase.
Variablen beginnen klein: entwederSo oder_so.
Funktionsnamen sind oft unterschiedlich, ich mag es soAmLiebsten aber_auch_so oder GrossAmAnfang ist ok.

Diese Gross-Klein Regeln ermoeglichen einen enorm viel infos ueber den code zu erkennen ohne ihn lesen zu muessen.

Wenn ich zB irgendwo "Foo" sehe, weiss ich was es ist: ein Typ.
Wenn ich "foo" sehe, weiss ich, dass es eine Variable ist.

unheimlich praktisch. und man verschmutzt keine namen. denn das C ist zwar tragbar, aber nur solange man nicht ein I fuer interfaces einfuehrt. Dann wird es haesslich. aber ich verschmutze mir deshalb nie namen wenn es nicht sein muss. denn die namen sind alles was ich habe um meinen code schoen lesbar zu machen.

furchtbar ist deshalb ja auch das design der c++ standard library, aber da muss man halt durch

[Dravere]

Nexus schrieb:

Ok, durchaus verständlich. Aber konsequenterweise müsstest du dann nach jedem Block ein ; schreiben :p

Ja ich weiss, irgendwann gewöhn ich mich noch um ... irgendwann ... Aber das ist ja nicht so schlimm, daher ... SOON (tm)

Dravere schrieb:

..., aber ich schreib eben nicht so gern überflüssigen Code

Da bin ich anderer Meinung. Ich schreib oft gern überflüssigen Code. Denn alles was nicht vorhanden ist, ist im ersten Moment nicht klar. Beim Schreiben von Code ist es viel wichtiger, dass man ihn später wieder schnell versteht, als dass man den Code schnell schreiben kann. Die meiste Zeit verbringt man ja sowieso mit rumdenken, daher ist das egal ein bisschen mehr zu schreiben. Mit der Zeit hat man das auch so verinnerlicht, das geht voll automatisch.
Klar gilt es auch ein wenig sinnvoll zu unterscheiden. Ein void als leerer Übergabeparameter schreib ich auch nicht, da ich es sogar verwirrender finde. Wenn nichts übergeben werden soll, dann soll auch nichts stehen dort stehen

@Shade Of Mine,
Mein Problem bei diesem Stil ist die schlechte Unterscheidung zwischen Funktion und Objekt! Deshalb muss ich ausweichen auf grossgeschriebene Variablen und habe am Ende nichts mehr für die Klassen und muss daher das C einführen:

foo <- Objekt oder Funktion?

Bei mir:
foo <- Funktion!
Foo <- Objekt!
CFoo <- Typ!

I benutze ich nicht, nur ein S für structs, obwohl ich schon länger überlege, ob ich dieses nicht durch ein C ersetzen soll.

Grüssli

[Shade Of Mine]

Dravere schrieb:

Mein Problem bei diesem Stil ist die schlechte Unterscheidung zwischen Funktion und Objekt!

Weil es keinen unterschied gibt.
funktionen _sind_ objekte.
um genau zu sein: funktionen sind konstante functors.
deshalb mag ich es wenn objekte und funktionen gleich benannt werden.

template<typename F>
F foo(F f) {
  f();
  return f;
}

ist f jetzt eine funktion oder ein functor? man weiss es nicht, aber es ist egal. weil eine funktion nur ein spezialfall eines functors ist, mehr nicht.

[drakon]

Nexus schrieb:

Ja, aber nicht, wenn das Ende von main() erreicht wird. Bezüglich des Standards bin ich mir selber nicht sicher, aber ich schreib eben nicht so gern überflüssigen Code

Der Standard schreibt vor, dass die main Funktion, wenn kei Rückgabewert vorhanden ist das gleiche bedeutet, wie return 0;

Sonstige Diskussion:
Mir ist vorhin durch den Kopf, dass es bei der Schreibweise wirklich enorm viel einfacher wäre, wenn es "verbindliche" Regeln geben würde, so, dass man einen Stil hat, der möglichst perfekt ist und vielen passt. Wäre für alle einfacher, da könnte man dann fremden Code lese, als wäre es der eigene und muss nicht zuerst noch überlegen, wie jetzt dem seine Benennung wohl aussieht.

[Nexus]

Da ich meistens nur eigene und eher kleinere Hobby-Projekte habe, wende ich CamelCase fast überall an, weil ich es ästhetisch finde.
Sowas wie anyFunction gefällt mir nicht so. any_function bin ich mir von der Standardbibliothek gewöhnt und finde ich auch vertretbar, wende es selber aber nicht an. Deshalb AnyFunction

Dravere schrieb:

Ja ich weiss, irgendwann gewöhn ich mich noch um ... irgendwann ... Aber das ist ja nicht so schlimm, daher ... SOON (tm)

Ja, schlimm ist es wirklich nicht, und ich denke, das kannst du auch ruhig beibehalten

Dravere schrieb:

Da bin ich anderer Meinung. Ich schreib oft gern überflüssigen Code. Denn alles was nicht vorhanden ist, ist im ersten Moment nicht klar. Beim Schreiben von Code ist es viel wichtiger, dass man ihn später wieder schnell versteht, als dass man den Code schnell schreiben kann. Die meiste Zeit verbringt man ja sowieso mit rumdenken, daher ist das egal ein bisschen mehr zu schreiben. Mit der Zeit hat man das auch so verinnerlicht, das geht voll automatisch.

Vielleicht hab ich mich ein wenig unglücklich ausgedrückt. Code, der das Verständnis erleichtert, schreib ich natürlich auch lieber mehr. Aber return 0; und int argc, char** argv gehören meiner Ansicht nach nicht dazu.

Ich kommentiere beispielsweise relativ oft, und versuche, wenn möglich, komplexe Ausdrücke auf mehrere Zeilen zu verteilen. Ein ++ in einem Ausdruck mit anderen Operatoren findet man bei mir zum Beispiel kaum.

drakon schrieb:

Sonstige Diskussion:
Mir ist vorhin durch den Kopf, dass es bei der Schreibweise wirklich enorm viel einfacher wäre, wenn es "verbindliche" Regeln geben würde, so, dass man einen Stil hat, der möglichst perfekt ist und vielen passt. Wäre für alle einfacher, da könnte man dann fremden Code lese, als wäre es der eigene und muss nicht zuerst noch überlegen, wie jetzt dem seine Benennung wohl aussieht.

Ja, im Grunde genommen kein schlechter Ansatz, aber mir scheint das ein wenig utopisch. Erstens ist es nicht so einfach, einen Stil zu finden, der den meisten passt und zweitens würden sich wohl trotzdem nicht alle dran halten. Oder meinst du ein in der Sprache verankertes Gebot? Also Compilerfehlermeldungen bei falschem Bezeichner?

Ich finde es ehrlich gesagt gut, dass man seinen Stil frei wählen kann. Denn bei einer allgemeingültigen Konvention wäre die Wahrscheinlichkeit gross, dass mir der Stil nicht passt

[Shade Of Mine]

idR sollte man sich bei dem eigenen Stil an den Stil der Standard Library der Sprache halten die man verwendet.

zumindest mache ich es so, nur bei c++ tuts mir immer weh da mach ichs oefters einfach wie oben von mir beschrieben.

denn was mich stoert:
accessors sind nicht als solche gekennzeichnet
typen und objekte sind nicht unterscheidbar (was ok waere, wenn typen objekte waeren)

[Dravere]

Shade Of Mine schrieb:

Weil es keinen unterschied gibt.
funktionen _sind_ objekte.
um genau zu sein: funktionen sind konstante functors.
deshalb mag ich es wenn objekte und funktionen gleich benannt werden.

Für mich ist eine Funktion eben eine Funktion, wenn sie als Funktion auftritt ... hä?
In deinem Fall mit dem Template sehe ich Funktionen als Objekte, wenn ich die Funktion aber direkt aufrufe, ohne Umweg über einen Funktionszeiger oder ein Template, dann seh ich das Ding immer noch als Funktion und nicht als Objekt.

Ich sehe die Funktionen daher weniger als Objekte, sondern eher als in Objekte verwandelbar. Vielleicht habe ich mich auch mit den Templategedanken noch nicht vollständig angefreundet. So richtig Powertemplate mässig programmiere ich noch nicht so lange, und die Templates haben bei mir einiges an der Notation verändern lassen

Nexus schrieb:

Aber return 0; und int argc, char** argv gehören meiner Ansicht nach nicht dazu.

Zu int argc, char** argv habe ich noch ein Edit gemacht. Das lasse ich meistens auch weg. Siehst du auch daran, dass ich den Fehler gemacht habe char* zu schreiben
Mir ging es nur darum zu zeigen, wie ich die Parameter hinschreibe. Normalerweise natürlich noch mit Variablen
return 0 ist wohl mehr Geschmacksache. Jede Funktion mit einem Rückgabewert hat ein return, wieso also bei der main weglassen? Lieber klar hinsetzen und definieren, so ist es und nicht anders.
Ich setz ja auch immer Default-Konstruktoren selber hin, Default-Destruktoren usw.

Grüssli

[Nexus]

Dravere schrieb:

Zu int argc, char** argv habe ich noch ein Edit gemacht. Das lasse ich meistens auch weg. Siehst du auch daran, dass ich den Fehler gemacht habe char* zu schreiben
Mir ging es nur darum zu zeigen, wie ich die Parameter hinschreibe. Normalerweise natürlich noch mit Variablen

Dass mir das nicht einmal aufgefallen ist, zeigt auch gerade, wie häufig ich es verwende
Und so schnell, wie der Thread hier wächst, hab ich dein Edit natürlich nicht mehr gesehen...

Was die Variablen betrifft: Ich schreib sie auch bei Deklarationen immer hin, damit man auch sieht, wofür sie zuständig ist.
So etwas finde ich total unübersichtlich:

int Function(int, float&, char*, std::vector<short>, const std::string&);

Dravere schrieb:

return 0 ist wohl mehr Geschmacksache.

Das seh ich auch so. Und main() ist bei mir eben eine "spezielle" Funktion, d.h. weil ich den Rückgabewert grundsätzlich nicht brauche, kommt sie mir wie eine void -Funktion vor. Es soll ja sogar Frevler geben, die void main() schreiben...

[Shade Of Mine]

Dravere schrieb:

In deinem Fall mit dem Template sehe ich Funktionen als Objekte, wenn ich die Funktion aber direkt aufrufe, ohne Umweg über einen Funktionszeiger oder ein Template, dann seh ich das Ding immer noch als Funktion und nicht als Objekt.

ok, vergiss templates:

foo(a, b);

ist foo eine funktion oder ein objekt? die semantik ist die selbe...

int foo(int i) {
  return i;
}

struct Foo {
  int operator()(int i) const {
    return i;
  }
};
Foo const foo;

der functor foo ist identisch mit der funktion foo. es sind in der benutzung keine direkten unterschiede erkennbar. eine funktion ist nur ein spezialfall eines funktors und mit verlaub gesagt ne ziemlich verbugte :p

Ich sehe die Funktionen daher weniger als Objekte, sondern eher als in Objekte verwandelbar.

bei mir ist entweder A ein B oder A ist kein B. A ist ein bisschen B gibts bei mir nicht.

[rüdiger]

Dravere schrieb:

Nexus schrieb:

Wieso eigentlich das Semikolon am Schluss?

Mehr Angewohntheit als Sinn. Ich finde es irgendwie gut, wenn die Einzeiler schön abgeschlossen sind. Semikolon ist ja so ein wenig der absolute Stop der Zeile in C++

Es ist aber schlicht und einfach ein Fehler. Die Syntax von C++ sieht da kein Semikolon vor und wenn dein Compiler das zufällig unterstützt, hast du Glück. Aber in der nächsten Revision motzt er vielleicht rum...

Gewöhne dir also so einen Fehler am besten gar nicht an. Egal welchen psychologischen oder ästhetischen Effekt du dahinter siehst.

[Dravere]

rüdiger schrieb:

Es ist aber schlicht und einfach ein Fehler.

Wieso ein Fehler? Wenn ich die Grammatik richtig in Erinnerung habe, dann kann man Semikolons hinschreiben wo und wie man will, naja fast ^^
Aber sowas sollte kein problem sein:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

int main()
{
  return 0;
}

Würd ich nie machen, aber würde mich erstaunen, wenn das irgendein Compiler ablehnen würde.

Im übrigen ist der "Fehler" leider schon seit LANGEM angewöhnt.

@Shade Of Mine,
Ja ja, schon gut. Man sieht es doch, dass ich selber Mühe damit habe, wenn ich es als "A ist ein bisschen B" definiere. Ich brauche da einfach etwas länger mich an sowas zu gewöhnen.
Die Probleme traten bei mir aber wirklich erst mit den Templates auf. Erst dort fing ich auch zum Beispiel oft an den operator () zu überladen usw. usf. Daher lass mir Zeit, das muss man doch zuerst verdauen
Wenn du wüsstest, wie meine Notation davor ausgesehen hat ...

Grüssli

[JustAnotherNoob]

Um zurück zum Urthema zu kommen

int main()
  {
  //Blubb
  }

also 2 und die Klammern rück ich mit ein(find ich einfach logisch? Fasst doch nur den Code zusammen und Einzeiler bei Kontrollstrukturen werden doch auch eingerückt?)

[_matze]

Labutator schrieb:

Meine geschweiften Klammern setze ich direkt hinter die Funktion/Klassendeklaration.
Ein Tab für jeden weiteren block.

bool f(){
	return true;
}
int main(){
	if(f()){
		std::cout << "Hello World!" << std::endl;
	}
	return 0;
}

Das mache ich genauso! Ich setze nur noch ein Leerzeichen vor die geschweifte Klammer. Ansonsten finde ich diese Art der Notation genau richtig, da man einfach keine Zeilen unnötig verschwendet.

Labutator schrieb:

Und ich weiss nicht wieso,aber sowas:

int main()
{
	return 0;
}

finde ich ziemlich hässlig.

Ich weiß wieso: weil es hässlich ist! Na ja, Ansichtssache...
Ganz schlimm finde ich Konstrukte dieser Art:

if()
{
  //...
}
else
{
  //...
}

Die vielen unnötigen Zeilen verschwenden Platz und schaden imho der Übersicht.

EDIT: Ach ja, @Topic: 2 Leerzeichen. Reicht locker und beugt horizontalem Scrolling vor.

[It0101]

_matze schrieb:

Ganz schlimm finde ich Konstrukte dieser Art:

if()
{
  //...
}
else
{
  //...
}

Die vielen unnötigen Zeilen verschwenden Platz und schaden imho der Übersicht.

Warum?
Ich finde es viel übersichtlicher als deine Variante, da man die (versteckte) geschweifte Klammer hinter dem Bedingungsblock (vom if) leicht übersehen könnte

Und es ist ja nun nicht so, dass die Zeilenanzahl eines Programm begrenzt ist

Also ich verwende If-else-Konstrukte genauso wie du sie beschrieben hast und find es sehr übersichtlich.

[otze]

_matze schrieb:

if()
{
  //...
}
else
{
  //...
}

Die vielen unnötigen Zeilen verschwenden Platz und schaden imho der Übersicht.

Nein, tun sie nicht :). Eine normale C++ funktion sollte immer sehr kurz sein, die einzelne Klasse hat nicht viel Funktionalität. Und bei kurzen Funktionen hat man kein scrolling Problem. weder horizontal noch vertikal.Also kann man da ruhig Platzäßig etwas rumsauen und dafür sorgen, dass die Notation informativ und gut lesbar ist. Anders siehts dann natürlich wieder bei einer 200 Zeilen Funktion aus, aber sowas macht man einfach nicht

[_matze]

It0101 schrieb:

Warum?
Ich finde es viel übersichtlicher als deine Variante, da man die (versteckte) geschweifte Klammer hinter dem Bedingungsblock (vom if) leicht übersehen könnte

Nun ja, für mich beginnt der Block mit dem "if", da brauche ich nicht extra eine deutlich sichtbare, geschweifte Klammer. "if" und Klammer sind auf der gleichen Ebene und beginnen bzw. beenden den Block.

It0101 schrieb:

Und es ist ja nun nicht so, dass die Zeilenanzahl eines Programm begrenzt ist

Das nicht, aber die Zeilenanzahl pro sichtbaren Bildschirm ist begrenzt. Und da schaden imho 'überflüssige' Zeilen der Übersicht. Ich sehe einfach mehr relevante Zeilen pro Schirm.

It0101 schrieb:

Also ich verwende If-else-Konstrukte genauso wie du sie beschrieben hast und find es sehr übersichtlich.

Alles Ansichtssache! Jeder so, wie es ihm beliebt. Letztlich musst du ja mit deinem Code arbeiten, nicht ich. Also sollte der auch nach deinen Vorstellungen notiert werden.

[Fellhuhn]

Hängt einfach von dem Projekt ab an dem ich arbeite bzw den Styleguide der dafür vorgesehen wurde. Momentan sind es vier Leerzeichen pro Einrückung und geschweifte Klammern etc. auf einer extra Zeile. Privat würde ich zwei Leerzeichen nehmen und die Klammern auf die gleiche Zeile wie die "Einleitung" des Blocks legen.

Da mein aktuelles Projekt aber durchaus Funktionen hat, die locker die 2.000 Zeilen sprengen (ja, einzelne Funktionen...), interessiert mich da die Übersicht recht wenig. Aber der Code ist teilweise auch über 10 Jahre alt und hat entsprechend über 100 Programmierer gesehen. Chaos.

[_matze]

otze schrieb:

Also kann man da ruhig Platzäßig etwas rumsauen und dafür sorgen, dass die Notation informativ und gut lesbar ist.

Da hast du im Grunde Recht. Ich sehe nur keinen Vorteil zwischen

if()
{
  //...
}

und

if() {
  //...
}

Bei beiden Notationen ist der Blockbeginn (imho ) gut sichtbar. Bei meiner Variante habe ich jedoch u.U. auch die Möglichkeit, mir 2 oder 3 (eventuell zusammenhängende) Funktionen auf einmal anzusehen.

otze schrieb:

Anders siehts dann natürlich wieder bei einer 200 Zeilen Funktion aus, aber sowas macht man einfach nicht

Da gebe ich dir vollkommen Recht! Man macht es einfach nicht! Anders sieht es natürlich bei bereits bestehendem, fremdem Code aus. Bei uns gibt es durchaus Funktionen, die die 200-Zeilen-Grenze locker sprengen, auch wenn's eher die Ausnahme ist. Aber da bin ich froh, wenn ich möglichst viel auf einmal sehe. Das ist nämlich alles nach meinem bevorzugten Schema notiert. Ein Verlust der Übersicht besteht ja nach meiner Ansicht nicht. Schlimm, wirklich, wirklich schlimm finde ich hingegen das komplette Fehlen von Kommentaren...