3. Codeorganisation (c/c++)

Codeorganisation (c/c++)

  • C
     

    internal void bla() { 
    int fasel = 1; 
    . 
    . 
    . 
	if(fasel == 1) { 
        CallSomething(fasel); 
        SpuckNicht(); 
		using(allesNurNichtNextGen) { 
            der da hinten is haesslich 
            . 
            . 
            . 
            der daneben aber auch 
        } 
    } 
}

    Krankheit... 👎 🤡

    0
  • _

    Mr Evil schrieb:

    allein aus dem grund weil man meiner meinung nach viel schneller sieht welche bloecke wo zusammengehoeren

    Ansichtssache. Ich sehe keinen Unterschied, egal ob nun ein if oder eine öffnende Klammer auf derselben Ebene steht wie die schließende Klammer. Ist für mich qualitativ gleichwertig, nur das ich bei ersterem eine Zeile spare (und beim else nochmal zwei!). Aber na ja, diese Diskussion ist wohl so alt wie die Programmiererei an sich... 🙂

    0
  • J

    😛 hab mir Variante 3 angewöhnt

    void foo()
  {
  bar();
  }
    0
  • _

    JustAnotherNoob schrieb:

    😛 hab mir Variante 3 angewöhnt

    void foo()
  {
  bar();
  }

    Dein Glück, dass es keinen Würge-Smiley gibt! 😃

    0
  • ?

    Warum kann man eigentlich nicht schon lange die Editoren so einstellen, dass sie die Quellcodeformatierung unabhängig von der gespeicherten anzeigen? Dann könnte es jeder so anzeigen lassen wie er will.

    0
  • S

    ~fricky schrieb:

    btw, mich wundert's nur, warum die k&r-freaks funktionsaufrufe nicht auch so schreiben:

    k_and_r_sucks (
   123,
   "hello"
);

    das wäre doch wenigstens konsequent.
    🙂

    Ist doch in jeder Sprache gang und gaebe und zwar im k&r style.
    natuerlich nur bei funktionen die zu lange parameterlisten haben - aber egal welchen stil die leute verwenden, da gehen sie ploetzlich wieder auf k&r.

    aber wie bashar gezeigt hat, mit ( in einer eigenen zeile sieht das ja auch selten daemlich aus.

    0
  • ?

    die java c++ flamewars sind eindeutig besser, als die klammersetzungs flamewars

    0
  • A

    Hallo,

    bezüglich der Syntaxformatierung schliesse mich Mr. Evil an.
    Mal eine Frage nebenbei, wie ist es denn bei Liebhabern der ersten Methode mit switch case Blöcken, schreibt ihr es auch so:

    switch (a) {
    case 0: {
        break;
    }
}

    Oder wie?

    0
  • A

    abc.w schrieb:

    ..., schreibt ihr es auch so:

    switch (a) {
    case 0: {
        break;
    }
}

    Da die innere Klammer nicht benötigt wird, wird eine Antwort wohl nicht unbedingt kommen 😉

    0
  • C

    asc schrieb:

    abc.w schrieb:

    ..., schreibt ihr es auch so:

    switch (a) {
    case 0: {
        break;
    }
}

    Da die innere Klammer nicht benötigt wird, wird eine Antwort wohl nicht unbedingt kommen 😉

    Manchmal schon:

    int main()
{
	switch(0)
	{
	case 1:
		int x = 0;
		break;
	case 2:
		break;
	}
}

    error C2360: initialization of 'x' is skipped by 'case' label
see declaration of 'x'

    MfG

    0
  • C

    ...

    0
  • D

    Variante 2 ... Symmetrie hat oberste Priorität bei mir.

    0
  • E

    es ist alles halt auch recht subjektiv

    mein empfinden findet die zweite auch daher besser da so der code "angenehmer" zu sehen ist - wirkt klarer und aufgeraeumter, und somit auch uebersichtlich

    wenn ich viel code sehen und verstehen muss - wirkt variante 1 so "kompakt" und "gepresst" - das man sich auf dem ersten blick erst einmal erschlagen fuehlt

    aber wie gesagt, ist geschmackssache - da gibts keine "einigung" - so lange der code konsistent ist, und wenn man viele verschiedene sachen entwickelt wie wir, der code ueberall gleich geschrieben ist, passt das schon

    ich hatte auch mal ne zeit lang variante 1 bei privaten code probiert - war schnell wieder zur zweiten zurueck gewechselt

    0
  • _

    Mr Evil schrieb:

    aber wie gesagt, ist geschmackssache - da gibts keine "einigung" - so lange der code konsistent ist, und wenn man viele verschiedene sachen entwickelt wie wir, der code ueberall gleich geschrieben ist, passt das schon

    👍 Richtig, dass sich alle auf eine Variante einigen und man sich nicht ständig umstellen muss, ist eigentlich das Wichtigste. Bei uns ist Variante 1 übrigens Pflicht, was ja zum Glück auch meiner persönlichen Vorliebe entspricht. Um wem es anders geht, der gewöhnt sich nach kurzer Zeit dran.

    0
  • B

    ich benutze auch immer variante 1.. wobei ich im fremden code zu 99% variante 2 sehe... d.h. 99% der Programmierer sind bettnässer?

    0
  • P

    BorisDieKlinge schrieb:

    ich benutze auch immer variante 1.. wobei ich im fremden code zu 99% variante 2 sehe... d.h. 99% der Programmierer sind bettnässer?

    😃

    0
  • E

    "scriptkiddys bevorzugen variante 1 weil man so profesionalitaet und komplexitaet vortaeuschen kann - schaut halt professioneller aus" #DuckUndWeg #gg

    0
  • A

    Ich finde, es geht hier nicht um die Geschmackssache oder Vorliebe, sondern, es geht um eine Art Phylosophie oder Strategie, bei der man vermeiden möchte, viel Zeit am Debugger zu verbringen. Was nützt einem ein kompakter Code, wenn man keine gute Stelle findet, wo man ein Breakpoint setzen könnte, oder bevor man ein Breakpoint setzt, zweimal hinschauen muss, dass man die richtige Zeile erwischt? (vielleicht werde ich alt...)
    Bei der ersten Methode finde ich sogar, dass der Programmierer mit Absicht seine Fehler im Code verstecken möchte. Bei der zweiten dagegen kostet es etwas Überwindung, sie zu benutzen, weil der Code dann "bloss gestellt ist", man sieht plötzlich alles und befürchtet vielleicht dann, dass der Reviewer etwas bemerkt - was im Prinzip gut wäre, bevor der Code freigegeben wird.

    0
  • _

    abc.w schrieb:

    Ich finde, es geht hier nicht um die Geschmackssache oder Vorliebe, sondern, es geht um eine Art Phylosophie oder Strategie, bei der man vermeiden möchte, viel Zeit am Debugger zu verbringen. Was nützt einem ein kompakter Code, wenn man keine gute Stelle findet, wo man ein Breakpoint setzen könnte, oder bevor man ein Breakpoint setzt, zweimal hinschauen muss, dass man die richtige Zeile erwischt? (vielleicht werde ich alt...)
    Bei der ersten Methode finde ich sogar, dass der Programmierer mit Absicht seine Fehler im Code verstecken möchte. Bei der zweiten dagegen kostet es etwas Überwindung, sie zu benutzen, weil der Code dann "bloss gestellt ist", man sieht plötzlich alles und befürchtet vielleicht dann, dass der Reviewer etwas bemerkt - was im Prinzip gut wäre, bevor der Code freigegeben wird.

    😮
    Meinst du das etwa ernst? Dein Posting ist eigentlich der Beweis dafür, dass dies reine Geschmackssache ist. Denn ich empfinde es gar nicht so wie du. Mir geht da keine Übersicht flöten, sondern ich gewinne imho Übersicht. Und erst recht verstecke ich nix. Dein Statement ist nun wirklich vollkommen subjektiv und selbst von dieser Warte völlig übertrieben.

    Tatsache ist doch, dass das Wichtigste für die Übersicht und Lesbarkeit des Codes das Einrücken ist, und das machen alle hier aufgeführten Varianten. Insofern akzeptiere ich auch alle (obgleich ich persönlich eben Variante 1 bevorzuge). Das solltest du auch tun.

    0
  • ?

    Was haltet ihr denn vom Pico-Style?

    if (a < b)
{ x = a + b;
  y = b; }

    😃

    @abc.w: Ich kann ehrlich gesagt nichts von dem was du sagst nachvollziehen.

    0
Anmelden zum Antworten