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

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

_matze

It0101 schrieb:

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.

Bist du nicht!

http://c-plusplus.net/forum/viewtopic-var-p-is-1555015.html#1555015

Tachyon

Fellhuhn schrieb:

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

Jo, dem kann ich nur zustimmen. Besonders übel wird es dann, wenn die SNiFF-"Verantwortlichen" das ganze Geraffel noch mit einer gehörigen Prise an restriktiven Perl-Skripten ganieren, die einem sehr merkwürdige Regeln aufzwingen. Diese grandiosen Skripte werden dann noch mit zuverlässiger Regelmäßigkeit befrickelt, und nach jedem dritten Frickelskript-Update lässt sich irgendwas nicht mehr bauen, weil es zuviel des Gefrickels war.

Edit: Pearl muss natürlich Perl heissen.

Tachyon schrieb:

Fellhuhn schrieb:

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

Jo, dem kann ich nur zustimmen. Besonders übel wird es dann, wenn die SNiFF-"Verantwortlichen" das ganze Geraffel noch mit einer gehörigen Prise an restriktiven Pearl-Skripten ganieren, die einem sehr merkwürdige Regeln aufzwingen. Diese grandiosen Skripte werden dann noch mit zuverlässiger Regelmäßigkeit befrickelt, und nach jedem dritten Frickelskript-Update lässt sich irgendwas nicht mehr bauen, weil es zuviel des Gefrickels war.

Was ist ein Pearl-Skript? Ich kenne nur einen Shop namens Pearl

pumuckl

Probe-Nutzer schrieb:

- 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:

mache das ähnlich, allerdings mit folgenden Abweichungen:
- public/private nicht eingerückt
- return in main nicht unbedingt
- Leerzeilen nur zur Abgrenzung von größeren Blöcken.

Bei Funktionen, wo ein Parameter nicht benutzt wird, schreibe ich dennoch seinen Namen auskommentiert mit (kommt z.B. bei virtuellen ab und zu vor):

void perhapsDoSomething(TargetType /*target*/)
{
  doNotMuch(); //
}