Einrücken mit Leerzeichen - wo ist das Problem?

SideWinder

Im anderen Thread haben die Grammar-Nazis der Code-Styling-Szene gerade stark dagegen gewettert. Wo ist denn das große Problem der Leerzeichen?

Advantages:
+ Ausrichten funktioniert

Disadvantages:
- manuelle Tab-Weite nicht einstellbar (hat da tatsächlich jemand etwas anderes als 4? Gibt's da noch Platzverschwender mit 8?)

Sonst fällt mir aber gar nichts dazu ein, warum also unbedingt Tabs?

MfG SideWinder

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

knivil

Ich ruecke mit Leerzeichen ein. Vorteil: es sieht ueberall gleich aus.

king- schrieb:

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

Das ist schlechter Programmierstil.

Man nimmt immer Leerzeichen, wenn es professioneller Code sein soll.

Grund:
Es ist denkbar, dass man sich beim Zeilenumbruch nich an "Tabs zum Einrücken und Spaces zum Ausrichten hält:

int meineSuperlangeFunktionMitParametern(blubber, blaba, gaga, exol, brahim, ..., n){

// wird zu:
int meineSuperlangeFunktionMitParametern(blubber,  
                                         blaba, 
                                         gaga, 
                                         exol, 
                                         brahim, 
                                         ..., 
                                         n){

Und wenn dann hier vor den Parametern Tabs verwendet wurden, weil man an Einrücken gedacht hat, wird's unschön.

knivil

Ich finde die Loesung aus Haskell ganz gut (es duerfen auch mehr Parameter in einer Zeile stehen):

int meineSuperlangeFunktionMitParametern(blubber, blaba, gaga, exol, brahim, ..., n){

// wird zu:
int meineSuperlangeFunktionMitParametern
( blubber
, blaba
, gaga
, exol
, brahim
, ... )

otze

SideWinder schrieb:

Advantages:
+ Ausrichten funktioniert

Ausrichten ist aber nicht Einrücken.

Du kannst gerne

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

schreiben, und das ist okay für mich. Das sieht gut aus unabhängig ob du 2er, 4er oder 8er tabs hast.

Genauso okay wäre für mich aber auch

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

wobei ich das Ausrichten durch das Einziehen einer weiteren Ebene im Code ersetzt habe. Auch das wird wahrscheinlich immer gleich ordentlich aussehen. Mit dem Bonusvorteil, das ich foo umbenennen kann ohne die Ausrichtung zu verstören.

Disadvantages:
- manuelle Tab-Weite nicht einstellbar (hat da tatsächlich jemand etwas anderes als 4? Gibt's da noch Platzverschwender mit 8?)

2 gibt es auch. Ich weiß, total gruselig. Ich benutze aber gerne mal 8 wenn ich keine monospace schriftart verwende (muss ich ja auch nicht, wenn ich nicht ausrichte).

B4ndit

Ich rücke nur mit Leerzeichen ein, bzw. lasse ich automatisch Tab in 4 oder 8 Leerzeichen beim Tippen umwandeln.

Grund: Es sieht überall gleich aus.

SideWinder

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

MfG SideWinder

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?

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

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?

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.

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;
}}}