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

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

[It0101]

Ja. Ich finde es auch schlimm wenn nicht oder minimal kommentiert wird (je nach Umfang der Funktion). Einen "inline - Einzeiler" brauch ich nicht mit 10 Zeilen Kommentaren versehen.

Ich bin auch gerade dabei meine entwickelten Klassen mit etwas Text und einer genauen Beschreibung aller Funktionen zu versehen

[_matze]

Fellhuhn schrieb:

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.

Andere Zeiten, andere Sitten. Ich habe damals in Clipper auch noch wesentlich längere Funktionen geschrieben. Das war auch nicht so tragisch bzw. irgendwie sogar von Vorteil, da ich keine komfortable IDE hatte, sondern nur einen simplen DOS-Editor (der gute, alte PE). Da konnte man nicht einfach über eine Listbox zur gewünschten Funktion springen oder gar Code-Blöcke einklappen oder andere Komfortfunktionen nutzen (find references vom VAX - genial!). Da hat es irgendwie Sinn gemacht, dass alle Zeilen zu einer bestimmten Aufgabe auch in einer (oder wenigen) Funktion(en) standen. Ich muss zugeben, damals habe ich auch oft Funktionen geschrieben, die mehrere hundert Zeilen lang waren. Na ja, die Zeiten haben sich geändert...

[Zeus]

rüdiger schrieb:

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.

Einspruch, Semikolon sind Synchronisierungssymbole für den Compiler und sind als Leeranweisung durchaus in der Grammatik so in C++ enthalten.

[It0101]

_matze schrieb:

Andere Zeiten, andere Sitten. Ich habe damals in Clipper auch noch wesentlich längere Funktionen geschrieben. Das war auch nicht so tragisch bzw. irgendwie sogar von Vorteil, da ich keine komfortable IDE hatte, sondern nur einen simplen DOS-Editor (der gute, alte PE). Da konnte man nicht einfach über eine Listbox zur gewünschten Funktion springen oder gar Code-Blöcke einklappen oder andere Komfortfunktionen nutzen (find references vom VAX - genial!). Da hat es irgendwie Sinn gemacht, dass alle Zeilen zu einer bestimmten Aufgabe auch in einer (oder wenigen) Funktion(en) standen. Ich muss zugeben, damals habe ich auch oft Funktionen geschrieben, die mehrere hundert Zeilen lang waren. Na ja, die Zeiten haben sich geändert...

Ich hab damals in Basic gar keine Funtionenen geschrieben, sondern nur Sprungbefehle benutzt Lang Lebe GOTO (und jetzt steinigt mich ^^)

[_matze]

It0101 schrieb:

_matze schrieb:

Andere Zeiten, andere Sitten. Ich habe damals in Clipper auch noch wesentlich längere Funktionen geschrieben. Das war auch nicht so tragisch bzw. irgendwie sogar von Vorteil, da ich keine komfortable IDE hatte, sondern nur einen simplen DOS-Editor (der gute, alte PE). Da konnte man nicht einfach über eine Listbox zur gewünschten Funktion springen oder gar Code-Blöcke einklappen oder andere Komfortfunktionen nutzen (find references vom VAX - genial!). Da hat es irgendwie Sinn gemacht, dass alle Zeilen zu einer bestimmten Aufgabe auch in einer (oder wenigen) Funktion(en) standen. Ich muss zugeben, damals habe ich auch oft Funktionen geschrieben, die mehrere hundert Zeilen lang waren. Na ja, die Zeiten haben sich geändert...

Ich hab damals in Basic gar keine Funtionenen geschrieben, sondern nur Sprungbefehle benutzt Lang Lebe GOTO (und jetzt steinigt mich ^^)

Leider gibt es keinen Steinigungs-Smiley!

Habe ich aber bei meinen ersten Gehversuchen auch. Das stand schließlich so in meinem AmigaBASIC-Buch für Kinder drin...

[It0101]

Naja die ersten Programmierversuche (damals auf nem 8086 Laptop mit zwei DD-Diskettenlaufwerken und ohne Festplatte - anno 1991 ) haben uns schließlich heute zu C++ geführt

jaja damals nach der Wende - wir hatten ja nix ^^

Edit: ich weiß bis heute nicht was mich damals dazu gebracht hat die "QBASIC.EXE" zu starten... 99 von 100 Kindern hätte die Datei absolut kalt gelassen