Einrücken mit Leerzeichen - wo ist das Problem?

B4ndit

knivil schrieb:

@B4ndit: Was willst du damit sagen?

Nix, einfach nur mal Zeugs das total aus dem Kontex gerissen so hingeschrieben wurde...Ich bin manchmal so^^

Shade Of Mine

Sone schrieb:

Naja, Kellerautomats Variante ist IMHO sinnvoller, da da auch direkt die Syntax des ::-Operators enthalten ist.

ich sehe keinen relevanten unterschied. Beide Varianten sind gleichwertig - sie verhindern ein zu starkes rechts wandern des codes.

PS:
ich habe darueber meditiert und finde das untereinander schreiben der namespaces besser lesbar, da die namen der namespaces zusammen gruppiert sind und ich auf einen blick alle namen lesen kann. bleibe aber dabei dass es im prinzip egal ist.

hustbaer

Ich rücke aktuell jeden Namespace in einem File ein, in dem im betroffenen File etwas definiert wurde.
Also so:

namespace Foo { BLAH_DONT_INDENT_NAMESPACE // <- Sinn des komischen Makros: wenn nach der "{" noch was steht rückt MSVC 2005 
namespace Bar { BLAH_DONT_INDENT_NAMESPACE //    (mit dem ich leider aktuell noch arbeiten muss) den Namespace-Inhalt nicht ein 
namespace Baz {

    class ABazThing {};

} // namespace Baz
} // namespace Bar
} // namespace Foo

Aber

namespace Foo {

    class AFooThing {};

    namespace Bar { BLAH_DONT_INDENT_NAMESPACE
    namespace Baz {

        class ABazThing {};

    } // namespace Baz
    } // namespace Bar

} // namespace Foo

bzw.

namespace Foo { BLAH_DONT_INDENT_NAMESPACE
namespace Bar { BLAH_DONT_INDENT_NAMESPACE
namespace Baz {

    namespace {

        void HelperFunction()
        {
        }

    } // namespace

    void BazFunction()
    {
    }

} // namespace Baz
} // namespace Bar
} // namespace Foo

Sone

namespace Foo { 

    class AFooThing {}; 

    namespace Bar { BLAH_DONT_INDENT_NAMESPACE 
    namespace Baz { 

        class ABazThing {};

Ist das von der Namensgebung nicht recht redundant?

knivil

Sone schrieb:

Naja, Kellerautomats Variante ist IMHO sinnvoller, da da auch direkt die Syntax des ::-Operators enthalten ist.

Man kann fuer alles fadenscheinige Gruende finden, vernuenftig sind sie trotzdem nicht. Ich habe es dem Google coding style entnommen und habe es fuer mich als gut empfunden. Mehr nicht.

namespace Foo { BLAH_DONT_INDENT_NAMESPACE // <- Sinn des komischen Makros: wenn nach der "{" noch was steht rückt MSVC 2005 
namespace Bar { BLAH_DONT_INDENT_NAMESPACE

Das wird nicht besser. Nichtmal VS 2013 Preview kann namespaces gesondert behandeln.

Sone

Man kann fuer alles fadenscheinige Gruende finden, vernuenftig sind sie trotzdem nicht.

Das ist kein fadenscheiniger Grund. Ich kann so direkt sehen, wie die Qualifizierung eines Namens aussieht.

Shade Of Mine

Sone schrieb:

Man kann fuer alles fadenscheinige Gruende finden, vernuenftig sind sie trotzdem nicht.

Das ist kein fadenscheiniger Grund. Ich kann so direkt sehen, wie die Qualifizierung eines Namens aussieht.

und das geht beim untereinander schreiben der namen nicht?

Sone

Shade Of Mine schrieb:

Sone schrieb:

Man kann fuer alles fadenscheinige Gruende finden, vernuenftig sind sie trotzdem nicht.

Das ist kein fadenscheiniger Grund. Ich kann so direkt sehen, wie die Qualifizierung eines Namens aussieht.

und das geht beim untereinander schreiben der namen nicht?

Nein, weil ich dann im Kopf die einzelnen Namensraumnamen* hintereinander platzieren muss.

Gut, eigentlich ein fadenscheiniger Grund. Aber deswegen mag' ich nun mal diese Syntax.

~*: Genialer Neologismus~

hustbaer

Sone schrieb:

namespace Foo { 
  
    class AFooThing {}; 
  
    namespace Bar { BLAH_DONT_INDENT_NAMESPACE 
    namespace Baz { 
  
        class ABazThing {};

Ist das von der Namensgebung nicht recht redundant?

Ist die Frage von der Sinnhaftigkeit her nicht ziemlich leer?

Natürlich ist es redundant. Es ist auch nur ein Beispiel, dass "AFooThing" kein Name ist der einem bestimmten Benamsungsschema entspricht sollte klar sein. Es ist ja kein Benamsungs-Beispiel sondern ein Einrückungs-/Formatierungs-Beispiel.

hustbaer

knivil schrieb:

Das wird nicht besser. Nichtmal VS 2013 Preview kann namespaces gesondert behandeln.

Es wird sogar schlimmer. Der Makro-Trick funktioniert mit VS 2013 nicht mehr. Bzw. genaugenommen kenne ich nun gar keinen akzepablen Trick mehr der funktioniert
Denn BEGIN_NAMESPACE Makros sind für mich ganz sicher nicht akzeptabel.

Shade Of Mine schrieb:

Warum nimmst du 8 Zeichen pro Tab?

Wir haben letztens in der Firma mal darueber diskutiert aber keiner hatte ein Argument warum man etwas anderes als 4 nehmen sollte.

Nun.
1. es ist Standard.
2. jeder weiß, dass ein Tab die Breite von 8 Spaces hat.

Ansonsten:
Wenn ich mit tw=8 Probleme mit der Zeilenlänge bekomme, sollte ich mir Gedanken machen, ob ich nicht vielleicht meinen Code umstruktieren sollte. Zigfach verschachtelten Conditionals kann auch ein Mensch nicht so gut folgen. Selten mag es vielleicht nötig sein.

Zwar lässt sich die Tabbreite bei Editoren und Terminalemulatoren meist recht einfach verändern, aber nicht immmer hat man Lust erstmal zu schauen, wie man ein Programm in der Hinsicht konfiguriert. Da fährt man mit dem (historisch bedingten) Standard 8 recht gut, wenn man sich dran gewöhnt hat.

Aber soll jeder machen wie er will. Hauptsache keine Spaces, das nimmt nämlich anderen die Möglichkeit den Code so zu betrachten, wie sie es für richtig halten.

Die Sprache Go hat das Problem übrigens schön gelöst. Die Go-Distribution bringt das Programm gofmt (inkl. Integration in gängige Editoren) mit, das einen einheitlichen Codeformatierungsstil durchsetzt. Nicht gofmt-behandelter Code ist in der Community verpönt. Nur wenige Meckern kurz wenn sie gofmt erstmalig kennenlernen und es nicht "ihrem" Stil entspricht. Letztendlich akzeptiert es aber doch jeder und der Vorteil ist imho nicht zu unterschätzen. Go-Code sieht zumindest oberflächlich nie ungewohnt aus.

hustbaer

kaaskuchn schrieb:

Shade Of Mine schrieb:

Warum nimmst du 8 Zeichen pro Tab?

Wir haben letztens in der Firma mal darueber diskutiert aber keiner hatte ein Argument warum man etwas anderes als 4 nehmen sollte.

Nun.
1. es ist Standard.
2. jeder weiß, dass ein Tab die Breite von 8 Spaces hat.

Das war vor Jahrmillionen vielleicht mal so. Mittlerweile ist Standard bei Source-Code 4.

8 Whitespaces sind immer noch Standard, jedenfalls wenn man mit OpenSource zu tun hat. Warum es 8 und nicht 4 sind ist ja wohl auch bekannt. Damit man auch mit müden Augen noch die Einrückungen problemlos erkennt.