Einrücken mit Leerzeichen - wo ist das Problem?

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.