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

[sothis_]

rüdiger schrieb:

P.S. Wer das anders macht ist vom Teufel besessen!

wenn dem so ist, bin ich äusserst gerne vom teufel besessen

[Blue-Tiger]

Tabs, auf Laenge 4 eingestellt. Geschweifte Klammern in einer eigenen Zeile (obwohl ich z. Z. ueberlege, das umzustellen).

[It0101]

Dem schließe ich mich an

[ceplusplus*loggedoff]

Labutator schrieb:

Meine geschweiften Klammern setze ich direkt hinter die Funktion/Klassendeklaration.

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

BRRRRRR GRRRRRR SDFJASDÖKLFJAÖSKLDF!
Boa ist das hässlich
Ehrlich, dann doch gleich so:

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

Noch unübersichtlicher! Juhu!
Jaja, so unterschiedlich sind wir
MfG

[Nexus]

Ich finde öffnende geschweifte Klammern auf der selben Zeile nicht nur unübersichtlich, sondern auch unschön, aber das ist natürlich Geschmackssache.

Ausnahme: Bei sehr kurzen Funktionen (evtl. inline) kann es legitim sein, obwoh ich das selber eigentlich nicht mache:

int Function() { return 21452; }

Was ich aber wirklich hässlich finde, ist das (einschliesslich den fehlenden Abständen bei Operationen):

int Function()
    {
    int x=2242;
    x*=2
    return x;
    }

[sothis_]

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

[Dravere]

Forum:

#include <iostream>

bool foo() { return true; };

int main(int, char*)
{
  // Zwei Leerzeichen!

  if(foo())
  { std::cout << "hello" << std::endl; }

  return 0;
}

In der IDE:

#include <iostream>

bool foo() { return true; };

int main(int, char*)
{
    // Tabulator (welcher ich im Forum nicht darstellen kann ^^)

    if(foo())
    { std::cout << "Hello" << std::endl; }

    return 0;
}

In Java:

public class CMainClass {

    // Tabulator (welcher ich im Forum nicht darstellen kann ...)

    public static boolean foo() { return true; };

    public static void main(String[] Arguments) {

        if(foo())
        { System.println("Hello"); }
    }
}

Und ja, ich bin vom Teufel bessesen. Schaut ruhig in mein Profil:
Interessen: Computer, Programmierung, Drachen, Mystisches, Rollenspiel

Grüssli

[Nexus]

Dravere schrieb:

bool foo() { return true; };

Wieso eigentlich das Semikolon am Schluss?

Deinen Stil finde ich übrigens gerade noch akzeptabel (obwohl ich es selber lieber übersichtlicher, sprich { und } auf eigenen Zeilen, habe, siehe oben)

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

[Hungarian?]

Dravere schrieb:

In Java:

public class CMainClass {

Wieso eigentlich das C im Klassennamen?

[Nexus]

Hungarian? schrieb:

Wieso eigentlich das C im Klassennamen?

Wohl, dass man es gerade als Klasse erkennt und schreiben kann:

CMainClass MainClass;

sothis_ schrieb:

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

Das mach ich höchstens bei sehr langen Ausdrücken, aber auch da eher nicht (ich bin diesbezüglich nicht ganz konsequent). Wenn, dann lasse ich aber immer Abstand zwischen return und der öffnenden Klammer. return(x); finde ich hässlich, sieht auch wie ein Funktionsaufruf aus.

[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...