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

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

Fellhuhn

_matze schrieb:

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!).

Naja, dann arbeite mal mit dem "modernen" IDE-Gedäns namens SNiFF und du weißt dann in etwa wo die Hölle liegt.

Chewie83

Variante 1:

int main() {
  //Code
}

Variante 2:

int main()
{
  //Code
}

Ich würde eigentlich Variante 1 bevorzugen, aber leider findet man da schwerlich Platz für die Initialisierungsliste. Und Konstruktoren und sonstige Funktionen/Prozeduren unterschiedlich zu notieren, würde auch keinen Sinn ergeben. Deshalb benutze ich Variante 2, allerdings nur in C++ eben wegen der Initialisierungsliste.

_matze

Fellhuhn schrieb:

Naja, dann arbeite mal mit dem "modernen" IDE-Gedäns namens SNiFF und du weißt dann in etwa wo die Hölle liegt.

Und die Wahl deiner Wunsch-IDE wird dir wohl (bei "Firmen-Gemeinschafts-Code" aus verständlichen Gründen) verwehrt. Das ist schade und fördert mit Sicherheit nicht deine Produktivität. Aber gegen den Firmenstandard kommt man einfach nicht an. Ich jedenfalls bin froh, dass wir das VS2005 nutzen und ich sogar (als einer der wenigen hier, die das wollten!) den VAX bezahlt bekommen habe.

Hallo,

hier meine "Angewohnheiten":

- geschweifte Klammern in eigenen Zeilen
- 4 Leerzeichen Einrückungen, grundsätzlich steht bei mir nichts innerhalb des Blocks in der Spalte, in der sich die geschweiften Klammern befinden, also auch z.B. public und private eingerückt
- return-Anweisung auch in main
- nach if, while usw. ein Leerzeichen bis zur auszuwertenden Bedingung
- binäre Operatoren sind links und rechts von einem Leerzeichen umgeben
- Funktionsargumente haben nach dem Komma ein Leerzeichen bis zum nächsten Argument
- nicht nur Aufführung der Typen, sondern auch Variablennamen bei (Member-)Funktionsdeklarationen
- Blöcke werden mit einer Leerzeile abgesetzt vom restlichen Code, auch "Blöcke" von Deklarationen/Definitionen:

a = 0;
// hier Leerzeile
while (a < b)
{
     //Code
}
// und hier Leerzeile
// ab hier weiterer Code

oder auch:

int a = 0;
Class c;
// Leerzeile
// in dieser Zeile steht anderer Code

- wenn Code so kommentiert wurde, dass er "direkt" am zu kommentierenden Code steht, dann wird wieder vom restlichen Code abgesetzt

// Leerzeile
// Kommentar, der sich auf die folgenden drei Zeilen bezieht
// Code
// Code
// Code
// Leerzeile

MfG,

Probe-Nutzer

_matze

Probe-Nutzer schrieb:

hier meine "Angewohnheiten":
[...]

Die Kommentare notiere ich genauso wie du. Ansonsten machst du mir zuviele Leerzeichen/-zeilen.

It0101

sagt mal gibt es eigentlich einen Thread wo jeder mal so reinschreiben kann, wann er so mit programmieren angefangen hat und was er so gemacht hat? Suchfunktion hat nix spezielles ergeben (2000 ergebnisse *heul*). Würde mich ja schonmal interessieren

Trau mich aber auch nicht einen aufzumachen, weil es eigentlich dafür kein geeignetes Forum gibt

_matze

It0101 schrieb:

sagt mal gibt es eigentlich einen Thread wo jeder mal so reinschreiben kann, wann er so mit programmieren angefangen hat und was er so gemacht hat? Suchfunktion hat nix spezielles ergeben (2000 ergebnisse *heul*). Würde mich ja schonmal interessieren

Trau mich aber auch nicht einen aufzumachen, weil es eigentlich dafür kein geeignetes Forum gibt

Findest du 'Rund um die Programmierung' nicht passend? Ich schon. Mach ruhig einen auf.

Nexus

Probe-Nutzer schrieb:

hier meine "Angewohnheiten":

- geschweifte Klammern in eigenen Zeilen
- 4 Leerzeichen Einrückungen, grundsätzlich steht bei mir nichts innerhalb des Blocks in der Spalte, in der sich die geschweiften Klammern befinden, also auch z.B. public und private eingerückt
- return-Anweisung auch in main
- nach if, while usw. ein Leerzeichen bis zur auszuwertenden Bedingung
- binäre Operatoren sind links und rechts von einem Leerzeichen umgeben
- Funktionsargumente haben nach dem Komma ein Leerzeichen bis zum nächsten Argument
- nicht nur Aufführung der Typen, sondern auch Variablennamen bei (Member-)Funktionsdeklarationen
- Blöcke werden mit einer Leerzeile abgesetzt vom restlichen Code, auch "Blöcke" von Deklarationen/Definitionen:

Dem stimm ich bis auf return 0; in main() vollständig zu

Und was Konstruktor-Initialsierungslisten betrifft, ich mach die folgendermassen:

MyClass::MyClass(int NewVar, short NewState, float NewDecimal)
: Var(NewVar)
, State(NewState)
, Decimal(NewDecimal)
{
    DoThis();
}

Viele mögen das jetzt unschön finden, aber ich finds übersichtlicher als alles auf einer Zeile, vor allem bei vielen Initialisierung.

Hey, ist das eigentlich normal, dass man im Forum momentan etwa 20 Sekunden braucht, um eine Seite zu laden?

It0101

Hey, ist das eigentlich normal, dass man im Forum momentan etwa 20 Sekunden braucht, um eine Seite zu laden?

scheinbar schon. Dachte schon ich bin der einzige dem das auffällt.

Nexus

Wobei 20 Sekunden noch verhältnismässig kurz waren. Vor etwa einer halben Stunde wartete ich über 5 Minuten. Einige Seiten konnten gar nicht mehr angezeigt werden. Momentan geht seltsamerweise alles wieder...

Ich hab das Problem mal in der Forentechnik gepostet (Link).