Einrücken mit Leerzeichen - wo ist das Problem?

Hier muss man einfach als Chef hart durchgreifen und das Umwandeln von möglichen Tabs zu Leerzeichen beim Speichern vorschreiben.
Bei guten IDEs kann man dann auch gleich festlegen, zu wievielen Leerzeichen ein Tab beim Speichern umgewandelt werden soll.

Wie der Programmierer seinen Tab dann für die Darstellung einstellt, kann dann am Ende egal sein.

B4ndit

x schrieb:

es funktioniert in Firmen nicht da dort alles schnell gehen muss, da bleibt keine zeit für solche unwichtigkeiten

Dann bist du in den falschen Firmen gewesen. Ich hatte immer Zeit für ein übersichliches Layout, zu mal das Eintippen von Code nur ein Bruchteil der Zeit bei mir ausmacht. Der Löwenanteil ist Planen, Recherchieren, Testen, Fehlersuche. Das eigentliche Code in die Tastatur hacken ist vom Zeitaufwand total unbedeutend. Da tippt jede Sekretären hundert mal mehr.

Aber vielleicht gibt es auch die Hacker aus den Filmen wirklich, die nur nonstop auf der Tastatur ihren Code runter hacken. Ich kann das jedenfalls nicht. Es sind vielleicht 10% meiner Zeit, die ich wirklich mit dem reinen Sourcecode zu tun habe.

8 Zeichen als Tabbreite soll wohl dafür gut sein, damit man auch noch mit müden Augen die Struktur erkennt. Ich code aber selten müde. Da legen ich mich lieber hin und mache dann frisch weiter. Genauso code ich ungern abends oder gar Nachts, bin eher der Frühaufsteher und kann ab 6:00 Uhr am besten Probleme lösen.

Club-Mate hasse ich übrigens auch, das Zeug schmeckt einfach zum k....

knivil

@B4ndit: Was willst du damit sagen?

Sone

once schrieb:

erfordert aber disziplin die die meisten progger nicht haben. leider

Wer nicht genug Disziplin besitzt seinen Code richtig aufzuräumen*, der hat auch zu wenig um Fehlerfreie und saubere Programme zu schreiben.

Namespaces mache ich so:

Übernehme ich mal, das sieht ja lecker aus.
Auch wenig bisher leider nicht so tief verschachtelte Namensräume hatte...

Der Löwenanteil ist Planen, Recherchieren, Testen, Fehlersuche. Das eigentliche Code in die Tastatur hacken ist vom Zeitaufwand total unbedeutend.

Interessant. Also wieder ein Beweis: Firmen ist der Code egal, das Ergebnis zählt?

* Was heißt hier schon richtig. Wir reden hier von Tabs und Spaces...

knivil

und ich so, namespaces warden nicht eingerueck:

namespace foo {
namespace bar {

class fun
{
...

};

}

Sone

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

namespace foo { namespace bar { namespace baz {
// =>
foo :: bar :: baz // Spaces zur Veranschaulichung

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.