Tabs vs. Leerzeichen

[dst]

In, in anderen Sprachen verfassten, Projekten stellt sich diese Frage zwar auch gelegentlich, aber bei Python ist sie von wesentlich größerer Bedeutung.

An verschiedenen Stellen habe ich nun gelesen, dass man für sein Python-Projekte am besten auf Leerzeichen setzt. Dass man sich zumindest auf eine Art der Einrückung festlegen sollte ist klar.

Da ich seit Ewigkeiten ein Verfechter von Einrückung per Tabulator bin und schon jetzt Probleme beim verwenden verschiedener Editoren habe, möchte ich von euch gerne wissen, was eurer Ansicht nach für Leerzeichen spricht.

Tabs sind meiner Erfahrung nach die bessere Wahl, da ein Tab eine klare und flexible Größe ist. Wenn man sich Projektintern auf vier Leerzeichen einigt, guckt derjenige, der mit acht (oder gar sechs?) Leerzeichen besser die Übersicht behält, in die Röhre.
Ich selbst bevorzuge sogar Tab-Weiten in Abhängigkeit des Editors. In Eclipse benutze ich z.B. eine geringere Einrückung als in vim.

Einzig bei auf mehrere Zeilen verteilten Statements (Funktionsaufrufe mit vielen Parametern o.ä.) muss man auf eine Bündigkeit zu einem spezifischen Teil der einleitenden Zeile zu setzen, was ich kaum als störend erachte.

[rayo]

Hi

Also ich denke wenn du strikt entweder tabs oder Leerzeichen nimmst sollte das ok sein. Häufiger oder besser gesagt fast überall nimmt man 4 Leerzeichen zum einrücken.

Ich verwende immer 4 Leerzeichen.

Probleme kriegst du wenn einer mit Tabulatoren arbeitet und der zweite mit Leerzeichen, dann weiss Python nicht, wieviel er nun für einen Tab nehmen soll.

Gruss

[Y0Gi]

Das Problem bei Tabulatoren ist, dass sie mal zwei, drei, vier, sechs, acht oder sonst wieviel Leerzeichene entsprechen. Und dann haut das schon bereits mit der 79-Spalten-Grenze schnell nicht mehr hin.

[dst]

In welchen Fällen ist denn eine 79-Spalten-Grenze ein Problem?

Ich denke mal, dass Du auf die Standard-Terminal-Dimensionen anspielst. Ist das wirklich ein relevantes Problem? Ich glaub der einzige Fall, wo ich noch mit solch einer Grenze zu tun habe, ist, wenn ich einen Server über eine Remote-Konsole wie Peppercon ansprechen muss - in dem Fall habe ich aber andere Probleme als eine tolle Darstellung von Python-Code.

Ansonsten sollten die meisten Editoren doch in der Lage sein, Tabweiten nach den Vorstellungen des Benutzers zu setzen. Gerade das ist in meinen Augen ein riesen Plus für Tabs.

Ich möchte wirklich nicht von mir auf andere schließen, aber das leuchtet mir im Moment nicht ein -- für Erleuchtung bin ich natürlich dankbar

[mitsuhiko]

Was gegen Tabs spricht und warum Python Programmierer 4 Tabs bevorzugen:

• Keine Tabs/Spaces Probleme
• EOL 79
• man kann sich an die Zeilenfortsetzungsregeln aus pep8 halten weil man mit Leerzeichen bis zur Klammer gehen kann. (Sonst müsste man tabs und Spaces mischen. Sehr nervig)

[jens]

I.d.R. kann man auch jeden Editor so einstellen, das er statt eines TAB Zeichens vier Leerzeichen automatisch einfügt. Normalerweise kann man dann auch mit ALT-TAB wieder eine Ebene zurück gehen. Von daher, alles kein Problem.

[Y0Gi]

EOL 79 kommt in der Tat von der gängigen Zeichenbreite in Terminals. Mal davon ab, dass man sich wohl auf keine andere Breite einigen können würde, ergibt es aber auch in weiteren Fällen Sinn:

• Man hat zwar eine tolle Auflösung von 1600x1200 oder mehr, aber benutzt eine IDE mit Class- und Dateibrowser, vertikaler Output-Pane, anderem Schnickschnack und möchte daneben noch seinen IM-Client und die Playlist im Auge behalten können.
• Drucken! Ist der Code breiter als ~79 Zeichen wird in der Regel umgebrochen (was sonst, abgeschnitten ist eine noch schlechtere Option) was praktisch die Grenze zur Unlesbarkeit überschreitet, wenn man nicht auf 9 Punkt Schriftgröße ausweichen will. Ich habe die Erfahrung gemacht, dass von Haus aus Ausdrucke von Textdateien in dicktengleichen Schriftarten wie z.B. Courier in so ziemlich der gleichen Schriftgröße und letztlich Zeichenbreite ausgedruckt werden. Würde auch Sinn machen, denn da besteht ja eine historische Verbindung zu den Terminals.

[gerold]

Hi!

Ich hatte mich gestern irgendwo im Code festgefressen. Deshalb habe ich die wichtigsten Bereiche des Codes ausgedruckt und bequem im Sofasessel noch einmal studiert -- und den Fehler gefunden.

Wie schön, dass mein Code bei 80 Zeichen umgebrochen wurde, sonst hätte ich den Code im Querformat ausdrucken müssen.

Das waren ja so schon 40 Seiten. Ich möchte gar nicht wissen, wieviele es im Querformat geworden wären...

Auch hier im Forum ist es eher schlecht, wenn man breiteren Code postet, da man dann ständig hin und her scrollen muss, damit man den Code lesen kann.

Und was die Diskussion um Tabulatoren und Leerzeichen angeht: Nimm vier (4) Leerzeichen und einen guten Editor, der dir beim Druck auf die Tabulator-Taste vier Leerzeichen ausspuckt.
Ich hatte mich am Anfang auf drei Leerzeichen eingeschossen, da ich denke, dass drei Leerzeichen gerade genug sind, um Einrückungen gut zu erkennen, aber das habe ich mir schnell wieder abgewöhnt und bin auf vier Leerzeichen zurück gekommen, da ich Schwierigkeiten hatte, Code mit anderen zu teilen oder Codebeispiele wiederzuverwenden. Entweder musste ich meinen Code, oder den Beispielcode anpassen. Das wurde mir auf die Dauer zu lästig. Diese Arbeit fällt weg, wenn **alle** Python-Programmierer gemeinsam vier Leerzeichen verwenden. So ist die Usance und sollte von allen eingehalten werden.

mfg
Gerold

[jens]

EOL 79, das sehen die django Jungs aber leider anders Siehe http://code.djangoproject.com/browser/django/trunk

Wobei unter http://www.djangoproject.com/documentat ... ding-style nichts darüber steht.

Ich bleibe bei 80 Zeichen.

[mitsuhiko]

EOL 79, das sehen die django Jungs aber leider anders Siehe http://code.djangoproject.com/browser/django/trunk

Die django Leute haben keinen Styleguide der EOL abdeckt. Die meisten haben EOL 79, adrian schreibt aber drüber hinaus.

pocoo hat EOL 90

[Y0Gi]

PEP 8 is t3h Law!

Und das sagt: EOL 79, keine Tabs, vier Leerzeichen Einrückung. Und gerade bei Python hat man ja nun wirklich nicht die Ausrede, man wüsste von keinem Styleguide oder nicht, welchen man nehmen sollte.

[dst]

Tja, dann werde ich wohl auch 4 Leerzeichen benutzen, allerdings nur weil dies bereits der Konsens ist und es gerade bei Python einleuchtet, dass alle auf den gleichen Standard setzen.

Die meisten restlichen Argumente halte ich nach wie vor zumindest für zweifelhaft oder sogar umkehrbar.

Naja, dann muss ich mal gucken, wie ich vim dazu bringe für Python auf Leerzeichen zu setzen. Hat jemand ne Ahnung, wie man bei vim-Scripting die aktive Sprache ausliest?
Also irgendwie sowas in die .vimrc:

Code: Alles auswählen

if irgendwas =~ "python"
    set expandtab
    set shiftwidth=4
    set softtabstop=4
    set tabstop=4
endif

[jens]

vielleicht hilft [wiki]Python-Programmieren mit Vim[/wiki]weiter?

[Mad-Marty]

Ich benutze zum beispiel 3 leerzeichen.
Wichtig ist einfach nur das du es konsistent machst.
IDEs erkennen das meist auch.

Tabs sind imo schlecht, weil es u.U. schlecht lesbar ist
Auserdem sind 80 zeichen schon sinnvoll, klar wenns mal auf 84 geht weils umgebrochen noch schlimmer wäre, dann ok.

Aber man sollte es zumindest versuchen unter 80 zu bleiben.

Und am besten du benutzt eine IDE wie WingIDE, dann kannst du bequem tabs zu spaces und umgekehrt konvertieren.
(Anmerkung für vim freunde: vim ist keine IDE :p )

[jens]

Ich benutze zum beispiel 3 leerzeichen.
Wichtig ist einfach nur das du es konsistent machst.

Wenn du closed source machst, ok... Wenn aber andere deinen Code auch benutzten sollen, dann ist es besser, man hat überall die selbe Einrückung... Ansonsten muß man beim codemischen immer die Leerzeichen anpassen...

[lunar]

Ich benutze zum beispiel 3 leerzeichen.
Wichtig ist einfach nur das du es konsistent machst.
IDEs erkennen das meist auch.

Das erzähl mal einem OpenSource Programmierer...

In der Realität sitzt man nicht alleine am Code, sondern arbeitet in der Regel im Team. Da ist es nicht wichtig, dass du konsistent bist, sondern dass alle konsistent sind.

Deswegen gibts ja Style Guides. Python stellt den Programmierer da nicht vor große Auswahl, den jenseits von PEP 8 gibt es nicht viel. Und was PEP 8 sagt, das wissen wir ja...

[BlackJack]

Noch ein Argument für 79/80 Zeichen pro Zeile: Häufiger als reinen Quelltext sehen sich viele Programmierer Patches oder Diffs aus der Versionsverwaltung in einem Terminal an.

Diese Diffs sind auch ein Argument gegen Tabs, weil man in Terminals normalerweise nicht einstellen kann, dass ein Tab nur 4 Zeichen entspricht und man damit dann wieder schnell die Standardbreite sprengt. Ausserdem gibt's in vielen Projekten Leute die sich alle Diffs vom Repository per Mail zuschicken lassen oder sich den Quelltext und Diffs per Webbrowser im Repository anschauen, in beiden Fällen hat man auch keine Kontrolle über die "breite" eines Tabs.

[oliver1974]

Ich gestehe freimütig, dass ich mit den 80 Zeichen auch so meine Probleme habe... Das ist schon ARG wenig, wenn dann noch halbwegs sprechende Variablennamen / Methodenbezeichner hat, die dann auch nicht gerade kurz sind, ist man ruckzuck über 80 hinaus.

Ich sehe die Gründe ja alle irgendwie ein, aber ich bekomme irgendwo immer Augenkrebs wenn ich öfters umbrechen muss, damit ich EOL79 erfülle.

Irgendwie muss ich das mit mir auch selber ausmachen.. momentan sind meine Python-Skripte eher kleine, übersichtliche Progrämmchen, weil man "eben mal ein Tool" braucht... Dass die Skripte in einem Diff angezeigt werden oder irgendwie mal auf einer Konsole, ist an der Grenze zur totalen Unwahrscheinlichkeit.... Gedruckt habe ich Quellcode übrigens schon seit JAHREN nicht mehr..... Bin überrascht, dass das wirklich noch Leute machen.. Aber jeder hat da wohl seinen eigenen "Style"

Es gibt x gute Gründe für EOL79, habt Ihr hier ja so schön dargelegt.. aber ich hab da eben irgendwie meine Probleme mit, ich komm leichter mit Quellcode klar der nicht diesen Umbruch drin hat...

Dass ich im Fall des Falles dann irgendwie Rücksicht nehmen muss (z.B. beim Posten in das Forum hier noch mal über den Code gehen und Umbrechen...) ist klar.

[jens]

btw. [wiki]Lange Zeilen im Sourcecode[/wiki]

[Y0Gi]

Gerade Side-by-side-Diffs im Web (z.B. Trac), in separaten Diff-Anwendungen oder in IDEs wie Eclipse sind nur wirklich nützlich, wenn die Zeichenbreite vernünftig begrenzt ist. Und selbst das ist bei 1024x768 schon knapp, wenn Sidebars dazu kommen, umso mehr.

Die Gründe für EOL 79 sind handfest, praktisch und jeder Entwickler sollte durch Ausdrucke und Diffs mehr als einmal davon profitiert oder sich bei Nichteinhaltung geärgert haben. Einleuchtender geht es meiner Meinung nach nicht.

Achso, und sowas wie "wenn ich auf Tab drücke, will ich X Leerzeichen Einrückung, und Ausrücken über Umschalt-Tab o.ä. sollte das entsprechend rückwärts machen" kann *jeder* vernünftige Programmiereditor, so auch das von mir nachwievor verwendete SciTE (und entsprechend alle, die auf dessen Hauptwidget aufbauen [und die Konfigurationsoptionen dazu zulassen/nicht verbauen]).