Einrücken mit Leerzeichen - wo ist das Problem?

hustbaer

Also ich hab' noch kaum Code gesehen der mit Tab=4 schlecht aussieht.
Code der auf endlich breiten Bildschrimen mit Tab=8 schlecht aussieht gibt's dagegen recht viel.
Tab=8 "hindert" einen nur daran bestimmte Dinge einzurücken -- wie z.B. namespaces.

Ansonsten...

Shade Of Mine schrieb:

PS:
da es unendlich viele Argumente pro Tabs und pro Leerzeichen gibt, denke ich dass das einzig sinnvolle ist die Tabbreite im Codingstyle zu definieren und dann zu definieren ob Tabs oder Leerzeichen verwendet werden sollen.

full ack

Kellerautomat

Eine Tabbreite hat in nem Codingstyle nichts verloren. Das ist eine persoenliche Einstellung des Programmiers.

Namespaces mache ich so:

namespace foo { namespace bar { namespace baz {
        blubb;
}}}

tntnet

Ihr habt ja Probleme. Die Diskussion lässt sich endlos führen und es wurden bereits Mannjahre dafür investiert, zu einem Ergebnis zu kommen.

Ich persönlich bevorzuge immer Spaces aber noch wichtiger ist es, einen einheitlichen Standard im Projekt zu haben. Wenn wir uns im Projekt auf Tabs einigen, dann sind es halt tabs.

Ein Vorteil von Spaces zur Einrückung wurde glaube ich noch nicht erwähnt: Es lässt sich leichter kontrollieren, ob das eingehalten wurde. Ein grep auf Tabs über alle Sourcen ist schnell gemacht. Ein grep auf Spaces ist natürlich auch schnell gemacht, wird aber viele false positives liefern. Also eigentlich wird es wohl fast den kompletten Sourcecode liefern, da in praktisch jeder Zeile ein Space vorkommt.

Das schlimmste sind Tabs und Spaces gemischt in Sourcecode. Das kommt in der Praxis bei alten Sourcen leider oft vor. Da muss man schon manchmal durch ausprobieren feststellen, mit welcher Tabeinstellung der Code überhaupt lesbar ist. Bei uns kommt viel Sourcecode vor, der nur bei Tabstop=5 lesbar ist. Oder aber eine Datei ist an einer Stelle mit Tabstop=8 gut lesbar, an einer anderen Stelle mit Tabstop=5. So sieht die Praxis aus und dabei lernt man Toleranz. Man muss es einfach akzeptieren, wenn man seine Zeit nicht mit Diskussionen über Tabs und Spaces verschwenden kann.

king- schrieb:

Das beste ist Tabs UND Spaces. Tabs zum Einrücken und Spaces zum Ausrichten.

erfordert aber disziplin die die meisten progger nicht haben. leider

hustbaer

tntnet schrieb:

Bei uns kommt viel Sourcecode vor, der nur bei Tabstop=5 lesbar ist. Oder aber eine Datei ist an einer Stelle mit Tabstop=8 gut lesbar, an einer anderen Stelle mit Tabstop=5. So sieht die Praxis aus und dabei lernt man Toleranz. Man muss es einfach akzeptieren, wenn man seine Zeit nicht mit Diskussionen über Tabs und Spaces verschwenden kann.

Toleranz zu lernen ist aber die falsche Lösung. Tab-Breite + Tabs vs. Spaces vorzuschreiben ist IMO die bessere Lösung. Dann verschwendet man nämlich keine Gehirnzellen mehr darauf so "unwichtige" (aber dennoch irritierende) Unterschiede auszublenden.

Ich kann mir wirklich kaum eine Situation vorstellen wo das (=Tab-Breite etc. vorschreiben) nicht möglich wäre. Viele, gerade grosse, Open-Source Projekte haben solche Vorschriften. Dort funktioniert es auch. Wieso sollte es dann nicht auch in Firmen etc. funktionieren?

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

Bashar

tntnet schrieb:

Ein grep auf Spaces ist natürlich auch schnell gemacht, wird aber viele false positives liefern. Also eigentlich wird es wohl fast den kompletten Sourcecode liefern, da in praktisch jeder Zeile ein Space vorkommt.

Mir scheint, du suchst das Regex-Pattern ^ für "Anfang der Zeile".

hustbaer

x schrieb:

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

Blödsinn

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.