Einrücken mit Leerzeichen - wo ist das Problem?

[otze]

SideWinder schrieb:

@otze: ich sehe immer noch nicht warum du gegen Leerzeichen bist...

Beim Ausrichten habe ich ja schon gesagt, was das Problem sein kann: Variablenumbenennungen die das Alignment zerstören -> was passiert bei automatisierten tools zum refactorn?

Und beim Einrücken ist es klar:
Würdest du gerne Code lesen, der mit 2-Leerzeichen statt tabs eingerückt ist, deren breite du selbst einstellen kannst? Umgekehrt: willst du deine Tabbreite jemandem aufzwingen der 2 oder 8 bevorzugt?

[einrücker]

Den einzigen Vorteil an Tabs scheint zu sein, dass man die Länge der Tabs auf 2, 4 oder 8 Spaces festlegen kann. Dann kann jeder den Code so lesen, wie er das möchte.

Nur ist das wirklich das irrelevanteste vom Stil.

Es stört mich viel mehr, dass jemand mit Tab=8 seinen Code nach

// 2x namespace + class + public + methode + for = 6
\t\t\t\t\t\tif(...){
\t\t\t\t\t\t\tfoo(
\t\t\t\t\t\t\t\ta,
\t\t\t\t\t\t\t\tb
\t\t\t\t\t\t\t);
\t\t\t\t\t\t}

formatiert nur weil das bei ihm dann so

if(...){
                                                        foo(
                                                                a,
                                                                b
                                                        );
                                                }

aussieht und er sicherstellen muss, dass dann die maximale Zeilenlänge nicht überschritten wird.

Dann kommt der nächste mit Tab=2 und schreibt alles in eine Zeile, was den mit Tab=8 unnötig aufregt.

Wenn maximale Zeilenlängen eingehalten werden sollen (und ~80 finde ich sehr sinnvoll um zwei Dateien nebeneinander in meiner Riesenfont darstellen zu können, mehr nur in Ausnahmefällen), dann muss man sich auf Tab=fix einigen.

Das Ideal der Tab-Fraktion wäre unformatierter Code-Markup

<anweisung>if<opt-keyword-space>(<lpar-space>a<opeq-space>==<opeq-space>b<rpar-space>)
<before-close-parenthesis>{<after-close-parenhesis>
<anweisung>foo<func-call-space>(
<lpar-space>a<before-comma-space>,<after-comma-space>
b<rpar-space)<semicolon-space>;</anweisung>
<before-close-parenthesis>}{<after-close-parenhesis></anweisung>

Dann hat man völlige Freiheit, den Editor so zu konfigurieren, dass der Code so ist, wie man gerne hätte. Tabs sind eine unvollständige Vorstufe.

Ich halte das aber für gefährlich. Gleicher Code sollte gleich dargestellt werden, damit man sich auch im Editor des Kollegen zurechtfinden kann. Und Tabs lenken von den eigentlichen Problemen ab.

if(...){
\tfoo( a,
\t\tb
\t    b
\t);
}

ist schnell mal unabsichtlich eingetippt, ist aber falsch formatiert. Dann beschäftigt man sich nur noch damit, wo man jetzt Tabs und wo Spaces setzt. Und das lenkt vom Programmieren ab.

Programmcode eintippen sollte einfach sein. Deshalb entweder nur Tabs oder nur Spaces. Nur Tabs geht nicht, also nur Spaces.

[otze]

einrücker schrieb:

Nur ist das wirklich das irrelevanteste vom Stil.

Begründung?

Es stört mich viel mehr, dass jemand mit Tab=8 seinen Code nach[..]

a) Es gibt wenige 8-taber
b) Es gibt wenige 8-taber die Code so einrücken, wie du hier vorschlägst. spontan würde ich 2-3 Ebenen weglassen. (2x namespace+class). Ich sehe das Prolem eher beim 4-Taber der seinen Code so einrückt, denn wie du bereits dargestellt hast, ist diese Einrücktiefe bei 8er Tabs nicht sinnvoll. Ansonsten liegt das Problem hier ja auch beim 8-Taber und nicht bei dir. Und genauso wie du im Notfall auch mal den Font einen höher oder kleiner stellst, wird auch der Taber seine Umgebung daran anpassen können. Imho konstruierst du hier ein Problem, das nicht relevant ist.

dann muss man sich auf Tab=fix einigen.

Jeder hat andere Prioriäten. Der eine will scrollen tunlichst vermeiden, der nächste möchte sinnvolle horizontale Abstände und der dritte möchte auch noch auf seinem mobilen device den Quelltext bequem darstellen können.

Das Ideal der Tab-Fraktion wäre unformatierter Code-Markup

Lass doch die Tabfraktion entscheiden, was ihr Ideal ist :).

Ich halte das aber für gefährlich. Gleicher Code sollte gleich dargestellt werden, damit man sich auch im Editor des Kollegen zurechtfinden kann.

a) Warum sollte das gefährlich sein b) In der Realität ist die Darstellung des Codes nicht das Problem, sondern der Rest des Editors. Wenn ich vor einem vi oder emacs arbeiten müsste, würde ich einen anderen Editor öffnen. Codeformatierung ist hingegen eine reine convenience Geschichte. Ein service für mich, wenn ich am eigenen Editor sitze. Da davon auszugehen ist, dass ich am eigenen Editor wesentlich öfter arbeite als am Editor von jemand anders, macht es Sinn, darauf zu optimieren.

if(...){
\tfoo( a,
\t\tb
\t    b
\t);
}

ist schnell mal unabsichtlich eingetippt

Das konstruierst du jetzt aber. Das passiert eventuell in einer Umgewöhnungsphas von Tab nach Tab+space, aber später nicht mehr. Nebenbei werden bei mir Tabs mit einem ganz feinen grauen Srich angezeigt.

Dann beschäftigt man sich nur noch damit, wo man jetzt Tabs und wo Spaces setzt.

Damit beschäftige ich exakt 0. QED. Mal angemerkt: wieviel Zeit am Tag verbringst du mit Spaces zählen?

Nur Tabs geht nicht, also nur Spaces.

Nur Tabs geht hervorragend. Ich hab schon Beispiele geliefert.

[Sone]

Dann beschäftigt man sich nur noch damit, wo man jetzt Tabs und wo Spaces setzt.

Nein, wieso? Es ist doch ganz logisch, wo man Tabs und wo man Spaces benutzt. Deinen Code könnte ein Schimpanse formatieren, da wette ich drum. Ich habe feste Regeln für die kleinsten Dinge, die ich auch einhalte, schon wie "Es kommt ein Leerzeichen zwischen die schließende Klammer und den Doppelpunkt bei einer Initialisierungsliste im Konstruktor".

ist schnell mal unabsichtlich eingetippt

Das wäre merkwürdig. Wieso sollte ich aus Versehen vier Spaces statt einem Tab (oder vice versa) eintippen?

[lehrzeichen]

Sone schrieb:

Das wäre merkwürdig. Wieso sollte ich aus Versehen vier Spaces statt einem Tab (oder vice versa) eintippen?

Das ist nicht nötig, die meisten Text-Editoren bieten Funktionen, um Tabs beim Speichern standardmäßig in x Leerzeichen (meist 1 Tab = 4 Leerzeichen) umzuwandeln.

Ohne mich genauer informiert zu haben, vermute ich, dass der vim das unterstützt.

[lehrzeichen - Edit]

Ich lag richtig:
http://vim.wikia.com/wiki/Converting_tabs_to_spaces

[Sone]

die meisten Text-Editoren bieten Funktionen, um Tabs beim Speichern standardmäßig in x Leerzeichen (meist 1 Tab = 4 Leerzeichen) umzuwandeln.

Klar, aber die Option verändert sich ja nicht zufällig mitten beim Ausrichten.

[Kellerautomat]

Ich benutze Tabbreite 8. Wer spaces benutzt hat seinen Code meist mit 4 Zeichen eingerueckt und ich muesste diesen durch ein Konvertierungstool jagen, daher sind Spaces Bullshit.

[Shade Of Mine]

Kellerautomat schrieb:

Ich benutze Tabbreite 8. Wer spaces benutzt hat seinen Code meist mit 4 Zeichen eingerueckt und ich muesste diesen durch ein Konvertierungstool jagen, daher sind Spaces Bullshit.

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.

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.

Denn wenn mit Unterschiedlicher Tabbreite gearbeitet wird, wird es zu notwendigen reformatierungs commits kommen. Und wenn das der Fall ist, dann hat man den falschen Style gewaehlt da man ploetzlich Arbeit mit etwas hat, dass keine Arbeit produzieren darf.

[Kellerautomat]

Shade Of Mine schrieb:

Kellerautomat schrieb:

Ich benutze Tabbreite 8. Wer spaces benutzt hat seinen Code meist mit 4 Zeichen eingerueckt und ich muesste diesen durch ein Konvertierungstool jagen, daher sind Spaces Bullshit.

Warum nimmst du 8 Zeichen pro Tab?

Weils mir am besten gefaellt.

[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.

[once]

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?

[x]

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

[Cheffe²]

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....