Frage

Ich habe bei der Python-Programmierung immer Tabulatoren zum Einrücken verwendet.Aber dann bin ich hier auf SO auf eine Frage gestoßen, in der jemand darauf hingewiesen hat, dass die meisten Python-Programmierer Leerzeichen anstelle von Tabulatoren verwenden, um Fehler zwischen Editoren zu minimieren.

Wie macht das einen Unterschied?Gibt es andere Gründe, warum man für Python Leerzeichen anstelle von Tabulatoren verwenden würde?Oder stimmt es einfach nicht?

Soll ich meinen Editor sofort auf das Einfügen von Leerzeichen statt Tabulatoren umstellen oder so weitermachen wie bisher?

War es hilfreich?

Lösung

Da PEP-8 sagt uns zu Verwendung Räume.

Andere Tipps

Müde von der Jagd nach Einzug Typos (8 Räume? Nein, 7 oops 9 ...) Ich meine Quellen geschaltet 'Tabs nur'.

1 tab == 1 Einzugsebene, Punkt

Der Punkt ist:., Wenn Sie die Vertiefung angezeigt werden sollen als 4, 8 oder pi / 12 Zeichenbreite, nur die Einstellungen in Ihrem Texteditor ändern, verwirrt sie nicht mit dem Code

(Ich persönlich verwenden 4 char Breite tab ... aber einige würden 3 oder 8 Raum bevorzugen oder sogar variabler Breite Schriftarten verwenden.)

Also sprach der Herr: Du sollst indent mit vier Räumen. Nicht mehr und nicht weniger. Vier ist die Zahl der Räume sollen ich Gedankenstrich, und die Zahl deiner Einrücken beträgt vier sein. Acht soll mich nicht indent, noch entweder indent ich zwei, mit der Ausnahme, daß ich dann zu vier gehen. Tabs sind direkt aus -. Georg Brandl

Verwenden Sie einen Editor, der Tabulatoren ZEIGT (alle Leerzeichen, was das betrifft). Sie programmieren, nicht einen Artikel schreiben.

I Registerkarten verwenden. Es gibt keinen Raum für einen Ein-Raum-Fehler in den Registerkarten (wenn Sie sie sehen können). Das Problem ist, dass Menschen unterschiedliche Editoren verwenden, und die einzige gemeinsame Sache der Welt ist: tab == indent, wie oben. Einiger Kerl kommt mit der Tab-Taste auf die falsche Anzahl von Leerzeichen oder tut es manuell und macht ein Chaos. TABs und einen echten Editor verwenden. (Dies ist nicht nur im Gegensatz zu dem PEP, es geht um C / C ++ und andere Leerzeichen unabhängige Sprachen auch).

/ Stufen von Soapbox

Mein Hauptgrund für Registerkarten über Räume mit der Rücktaste. Wenn ich auf einer Linie bin, und ich will ein Zeichen zurückzugehen zu entfernende eine Vertiefung auf nur, dass eine Zeile muss ich Backspace 4x schlagen, wenn es Räume waren; während, muss ich es nur einmal schlagen, wenn es ein Register ist.

Ich werde auch weiterhin Tabs verwenden, da artig angegeben wurde zuvor ist es einfacher, von Tabulatoren in Leerzeichen zu konvertieren, aber nicht umgekehrt.

Ich denke, ich ein einfaches Programm schreiben will, den Code mit Leerzeichen in Code mit Tabs umwandelt, weil ich hate Räumen freaking. Sie treiben mich an die Wand!

Oh! Und mit den Pfeiltasten navigieren links und rechts ist immer ein Schmerz im Arsch, wenn er Leerzeichen ist.

UPDATE: Sublime Text 3 löscht nun eine volle weichen Registerkarte mit der Backspace-Taste; obwohl, Pfeiltaste Navigation ist immer noch langweilig.

 Tabs vs. Leerzeichen für die Einrückung

UPDATE: ich jetzt benutzen vscode und schrieb auch ein TabSanity Erweiterung es Backspace zu lösen, löschen und Pfeil-Taste Navigation.

 TabSanity Erweiterung in Aktion

Der „pythonic“ Weg 4 Leerzeichen pro Einrückungsebene verwenden. Das Python-Interpreter wird jedoch Leerzeichen oder Tabs erkennen. Der einzige gottcha ist Sie darf niemals Leerzeichen und Tabulatoren mischen , das eine oder andere pflücken. Das heißt, die Spezifikation empfiehlt Räume, die meisten Entwickler Räume verwenden, so, wenn Sie einen wirklich guten Grund haben nicht zu, würde ich mit Leerzeichen gehen sagen.

So weit wie ich kann sagen, hier sind die Vor-und Nachteile von Registerkarten vs Räumen.

Pros von Registerkarten:

  • weniger Tastenanschläge einrücken, unindent erforderlich, und die Vertiefung durchqueren. (Auch wenn Ihre IDE etwas Platz-Einzug Klugheit hat es nie als Tabs so gut sein.)
  • Verschiedene Programmierer können verschiedene Tab Displaygrößen verwenden, wie sie wollen.
  • Sie können nie den Cursor „innen“ eine Vertiefung Charakter haben. Zum Beispiel sagen Sie einige Zeilen kopieren, mit Registerkarten können Sie auf vage in der Nähe des Anfangs einer Zeile Ihre Auswahl zu starten, und Sie werden alle von dem ersten Registerkarte erhalten. Mit Leerzeichen sind Sie wahrscheinlich den ersten Raum Charakter verpassen, wenn Sie die winzige Ziel zwischen ihm und dem Rand getroffen. Ebenso eine Vertiefung von einer Linie zu entfernen, die meisten Redakteure behandeln nicht Backspace drücken gut, wenn Sie den Cursor in der Mitte eines Vier-Raum Einbuchtung Charakter. Es wird in der Regel ein Leerzeichen entfernen. Mit Tabs funktioniert es wie erwartet.
  • Übereinstimmung mit anderen Sprachen, so dass Sie nicht zu verwenden, geben Sie Ihren Editor bis zu z.B. Registerkarten für C ++ / Java und Räume für Python.
  • Falsche Vertiefungen kann offensichtlicher sein (das heißt eine zusätzliche Registerkarte viel größer als ein extra Raum ist).

Nachteile von Registerkarten:

  • Die meisten Python-Programmierer verwenden Räume, so dass Sie gegen die Konvention gehen würde.
  • Räume Verwendung von Multi-line-Anweisungen auszurichten ist einfacher als Registerkarten. Sie könnte Verwendung tabs-für-Einzug, Leerzeichen-für-Ausrichtung, aber es scheint ein wenig riskant in Python!

Es gibt einige nicht-Probleme, die von einigen Leuten überblasen werden:

  1. Sie können Streuräume in Tabbed Vertiefung, die Schrauben Dinge bekommen: Praktisch alle IDEs / Editoren unterstützen die Visualisierung Leerzeichen, und es ist fast so, als wahrscheinlich, dass Sie Streu Tabs im Raum Einbuchtungen bekommen! Ich kann nicht sehen dies ohnehin ein häufiger Fehler ist. Außerdem die meisten Vertiefung Fehler durch Python gefangen wird und eine gute IDEs sollten unterschiedliche Vertiefungen markieren können.

  2. Sie können nicht Dinge ausrichten leicht mit Registerkarten: Dies gilt, wenn Sie sich für Charakter-perfekte Ausrichtung zu gehen, aber PEP-8 empfehlen dagegen, und Python spielt nicht gut mit mehreren Leitungen Aussagen trotzdem.

  3. Die Menschen haben Differenz Einstellungen für Registerkarte Anzeigegröße in ihren Editoren so Ihr Code an verschiedenen Orten anders aussehen werden. Ja, das ist eigentlich ein vorteilhaftes Merkmal von Tabs

Ich habe angefangen mit Leerzeichen mit anderem Python-Code konsistent zu sein, aber um ehrlich zu sein es frustrierend genug ist, dass ich wahrscheinlich wieder auf Registerkarten ändern. Viel hängt von den Fähigkeiten Ihrer IDE, aber in meiner Erfahrung kein Betrag der IDE-Unterstützung für den Raum Vertiefung ist so gut wie nur Registerkarten.

Also, wenn Sie wirklich mag es nicht inkonsistent mit die meisten (vermutlich nicht alle!) Python-Code, verwenden Sie Registerkarten und schalten Sie Leerzeichen Visualisierung und Einrückungen markieren (falls verfügbar). Der wichtigste Grund für mich ist eine einfache Auswahl und die (ziemlich bedeutende IMO) Reduzierung der Tastenanschläge. Einige Konventionen sind dumm.

Update : Ich habe entdeckt, dass es einen Editor in der ganzen Welt ist (mit Ausnahme von Unsinn wie Vim), die richtig Räume als Vertiefung unterstützt: Atom. Es hat eine Option „Atom tabstops“ genannt, die vier Räume macht verhalten, als ob es sich um eine Registerkarte in jeder Hinsicht waren (außer es, um die zu Größe in der Lage). Leider Atom ist ein ziemlich langsam und aufgeblähter Editor, aber das ist ein großartiges Feature, und wenn Sie Räume sind gezwungen, zu verwenden, könnte es eine gute Option sein. Hoffentlich eines Tages andere Editoren beginnen, sie zu unterstützen. Hier ist das Problem für VSCode .

ich auf einen Artikel vor kurzem kam dem Titel Python: Mythen über Einrückungen , die diskutiert diese und ähnliche Fragen. Der Artikel hat gute Gründe für die Verwendung von Räumen empfehlen, wenn Python-Code zu schreiben, aber es ist sicherlich Raum für Meinungsverschiedenheiten.

Ich glaube, es ist wahr, dass die meisten Python-Programmierer Leerzeichen verwenden nur.

einen Editor verwenden, die Sie Räume bis zum tabstop einfügen können, wenn Sie die TAB-Taste drücken, anstatt ein \ t Zeichen einzufügen. Und dann vergessen Sie es.

Sie können Tabs und Leerzeichen mischen ... aber ein Reiter gilt die gleiche Vertiefung als 8 Räume sein, so dass, wenn Ihr Editor eingerichtet ist, um eine Registerkarte zu berücksichtigen 8 Räume, die Sie für Probleme haben zu fragen, wenn sie das Mischen .

Der einzige Nachteil ich mit Verwendung von Leerzeichen anstelle von Tabulatoren Erfahrung ist, dass man nicht einfach eine Vertiefung Ebene entfernen können; Sie müssen vier Leerzeichen entfernen, anstatt nur eine Registerkarte.

Tabs Regel. Gleiche Argument für verschachtelte Schleifen und Sie möchten die äußere Schleife bringen „zurück“ 1 Stufe. Tipp: Wenn Sie alten Raum-durchlöchert Python-Code konvertieren in Registerkarten den TabOut Dienstprogramm als ausführbares verfügbar verwendet auf http://www.textpad.com/add-ons/ .

Ich fühle mich sehr stark, dass, was auch immer die historische Konvention, Tabs sind einfach eine bessere Wahl und sollen Räume in jeder zukünftigen Zeile von Python-Code geschrieben ersetzen. Wie ein inkompetent Tyrannen heraus treten. Meine Gründe dafür ist: simplicty als Kernwert . Verwenden Sie zwei oder vielleicht vier Zeichen für die semantische Aufgabe, ein? Es gibt keine Rechtfertigung über Tradition, IMO.

Editor-to-Editor Fehler tritt auf, wenn Sie gemischte Vertiefung innerhalb einer Datei . Dies stellt sich wie folgt dar: ein Code-Block ist mit 4 Leerzeichen eingerückt und dann einer Einbuchtung Ebene „in“, wird es mit Laschen eingerückt. Nun ist die Heiden, die dies taten (Tabs und Leerzeichen Mischen) hatte es so seine Tabs sind auch 4 Räume, so sieht er keine Probleme, und Python sieht keine Probleme.

Jetzt kommt unser Opfer später zusammen, und er hat seine Registerkarten auf 8 Räume. Jetzt ist unsere Opfer denkt, dass der Code alle gerädert aussieht, und fixiert es von eine Ebene der Vertiefung Entfernen , die nun den Code macht aussehen , wie es ist noch 2 Ebenen des Eindrucks, ist aber wirklich eine Ebene . An dieser Stelle bricht die Hölle los.

Die Lektion hier ist, dass Sie nie, nie, Tabulatoren und Leerzeichen mischen. Wenn Sie diese halten, dann ist es einfach, den Code in Leerzeichen oder Tabs zu reindent, unabhängig davon, welche Sie persönlich nutzen. Der beste Weg, Sie Tabs und Leerzeichen nicht, um sicherzustellen, mischen, immer python mit -tt laufen, was einen Fehler erzeugen, wenn Tabs und Leerzeichen gemischt werden.

Wie für Tabs und Leerzeichen, ich persönlich benutze Tabs so separater Einzug vom Aussehen - es ist viel einfacher, das Aussehen des Codes zu ändern, wenn es mit Tabulatoren eingerückt ist, als es mit Leerzeichen ist. Ich weiß, das steht im Gegensatz zu dem, was 99% des Python-Programmierers tun, aber das ist meine persönlich bevorzugt, und es ist in jedem Fall einfach eine Tabbed-Datei in einen Abstand ein zu konvertieren. Die Rückseite ist nicht immer der Fall, da Sie versehentlich 4 Leerzeichen in Strings Whack heraus können, etc.

Als ich zuerst Python zu lernen, war ich ein wenig von der Idee des bedeutenden weißen Raum beiseite legen, da die meisten Sprachen unflexibel es zu benutzen sind. Das heißt, ich war beeindruckt von Pythons Fähigkeit, eine Vielzahl von Einrückungsstile zu verstehen. Wenn man bedenkt, welche Art für ein neues Projekt zu verwenden, ich denke, es ist wichtig, daran zwei Dinge zu halten.

  1. Erstens ist es wichtig zu verstehen, wie Python Einzug interpretiert. Bryan Oakley erwähnte die Möglichkeit, Off-by-one Fehler bei der Verwendung von Tabs, aber das ist eigentlich nicht möglich, mit den Standard-Interpreter Einstellungen. Es gibt eine bessere Erklärung dafür in Learning Python , von O'Reilly Medien .

Grundsätzlich gibt es eine Variable (welche, indem einen Kommentar am Anfang einer Quelldatei # Tabulabreite verändert werden können:), die die Zungenbreite definiert. Wenn Python eine Registerkarte trifft, erhöht sich die Einbuchtung Abstand zum nächsten Vielfachen von Tabulatorbreite . Wenn also ein Raum, der durch eine Lasche folgte entlang der linken Seite der Datei eingetragen, das nächste Vielfache von Tabulatorbreite 8. ist Wenn ein Register von selbst eingegeben wird, das gleiche passiert.

Auf diese Weise ist es sicher, wenn Ihr Editor richtig konfiguriert ist, Tabs zu verwenden, und auch Tabs und Leerzeichen zu mischen. Solange Sie Ihren Editor-Tab eingestellt stoppt auf die gleiche Breite wie der Python Tabulatorbreite Deklaration (oder 8, wenn es nicht vorhanden ist). Es ist generell eine schlechte Idee, einen Editor mit einer Tabulatorbreite andere als 8 Räume zu verwenden, es sei denn, Sie auf die Registerkarte-Breite in der Datei angeben.

  1. Zweitens, viel von der syntaktischen Konstruktion von Python ist die Lesbarkeit des Codes und konsistenten Stil zwischen Programmierern auf dem gleichen Projekt zu fördern. Das heißt, stellt sich die Frage, für ein bestimmtes Projekt, was den Code machen die meisten lesbar von den Menschen an dem Projekt arbeiten . Sicherlich ist es eine gute Idee, eine konsequente Vertiefung Stil zu halten, aber abhängig von der Plattform und der im Rahmen des Projekts verwendet Editor, einen anderen Stil kann sinnvoll für verschiedene Projekte machen. Wenn es kein zwingender Grund, nicht entsprechen href="https://www.python.org/dev/peps/pep-0008/" rel="nofollow noreferrer"> PEP 8

Ich habe Projekte gestoßen, die eine Mischung aus Tabs und Leerzeichen erfolgreich nutzen. Grundsätzlich Räume werden verwendet, um kleine Abschnitte einrücken, wobei die Tatsache, dass es in einem eingekerbten Abschnitt ist, ist relativ unwichtig; während Registerkarten die Aufmerksamkeit des Lesers auf eine große Strukturmerkmal zeichnen verwendet. Zum Beispiel beginnen Klassen mit einer Lasche, die einfachen bedingte Kontrollen innerhalb einer Funktion zwei Leerzeichen verwenden.

Tabs sind auch nützlich, wenn mit großen Textblöcken gegliederte mehreren Ebenen zu tun. Wenn Sie aus 3-4 Ebenen der Vertiefung fallen, ist es viel einfacher, mit den richtigen Registerkarte aufreihen, als es mit der richtigen Anzahl von Räumen aufreihen ist. Wenn ein Projekt, nicht den PEP 8 empfohlen Stil zu verwenden ist es wahrscheinlich am besten einen Style Guide in eine Datei irgendwo zu schreiben, so dass die Vertiefungsmuster konsistent bleiben und andere Menschen explizit lesen können, wie sie ihren Editor konfigurieren lassen.

Auch hat Python 2.x eine Option -t Warnungen über gemischt Tabs und Leerzeichen und -tt zu erteilen, einen Fehler zu erteilen. Diese nur auf Misch Laschen und Zwischenräume innerhalb des gleichen Umfang angewendet. Python 3 übernimmt -tt und so weit ich gefunden habe, gibt es keine Möglichkeit, dass der Check zu deaktivieren.

Ich bin in erster Linie ein C ++ Programmierer, aber manchmal kleine Mengen von Python meiner Projekte umfassen. Ich benutze Tabs meinen C ++ Code einrücken. Das bedeutet, dass ich drei Möglichkeiten:

  1. Verwenden Sie Registerkarten in C ++ und Leerzeichen in Python. Dies ermöglicht es meine C ++ Dateien zu bleiben, wie sie sind, und ich folge der PEP-8 Empfehlung, aber ich bin inkonsequent in meinem Projekt.
  2. meinen C ++ Code ändern Räume zu verwenden. Auf diese Weise können alle meine Dateien in meinem Projekt konsequent sein, und ich folge der PEP-8 Empfehlung, erfordert aber mich zurück zu gehen und alle meine C ++ Dateien zu ändern. Ich halte dies für eine schlechte Sache, weil ich Tabs bevorzugen.
  3. Verwenden Sie Registerkarten in meinem C ++ Code und Python Code. Das macht mein ganzes Projekt konsequent und ermöglicht es mir, meine bevorzugte Einrückungsstil zu verwenden: Registerkarten. Der Nachteil ist, dass ich nicht den PEP-8 Standard bin nach.

Für meine Projekte, gehe ich im Allgemeinen mit der Option 3.

Die Erfahrung und PEP-8 beide schließen deutlich, dass das Mischen Räume und TABs vermieden werden. Wenn Sie sie mischen wollen, müssen Sie Leerzeichen in dem IDE sichtbar zu machen - aber dann verlieren Sie die Vorteile von Python Einzug Herstellung Bereichen gut sichtbar. Visualizing Leerzeichen in einem IDE-clutters die Anzeige.

Wenn es entweder TABs oder Räume, dann muss es Räume für einen einfachen Grund: Ein Schalter kann fast alle IDEs und Texteditoren automatisch Tabs mit Leerzeichen zu ersetzen, aber das Gegenteil ist nicht wahr.

Auch wenn es IDEs, die führenden Leerzeichen in einer Zeile Registerkarten automatisch konvertieren kann, wird dies schließlich führt eine Mischung aus Tabs und Leerzeichen zu haben. Betrachten Sie mehrzeilige Anweisungen wie Funktion mit vielen Parametern oder doc Strings nennt. Während „ascii-art“ auch, dass ein einzelner Raum nach den führenden Registerkarten übrig geblieben ist leicht durch Zufall passieren kann es vermieden werden soll.

Andere Antworten mehr Argumente für Registerkarten gebracht:

  • TAB Schlagen ist effizienter. Natürlich ist dies wahr, aber alle Text-Editoren erlauben die gewünschte Anzahl von Räumen, um sofort ein, wenn eine Tab-Taste gedrückt wird,
  • Einrücken / Dedenting ist einfacher, wenn nur eine Registerkarte statt 2/3/4/8 Leerzeichen zu entfernen. Das stimmt, aber die meisten Text-Editoren erlauben dies ohnehin automatisch zu tun: Block wählen Spiegelstrich / Dedent Basisfunktionalität eines Programmier-Editor sind, wie zu kommentieren / Auskommentierung. Wenn ein Text-Editor nicht hat dies umgesetzt, sollte es zumindest eine einfache Makrofunktionalität zu verwenden, mit denen man das Gleiche erreichen kann.
  • Verschiedene Programmierer wie verschiedene Einrückungen Breiten. Das ist wahr, und ein klarer Vorteil von TABs nur verwenden. Das Problem ist, die Interaktion mit anderen Personen und / oder Team. Für diese in der realen Welt zu arbeiten, würde jeder nur auf alle mit TABs zustimmen. Da dies nicht geschehen ist, funktioniert es nicht sowieso. In einem realen Szenario gibt es eine Reihe Richtlinien der Codierung, die ein Projekt auf jeden Fall stimmt, und das Verfahren des Einzugs ist sicherlich einer von ihnen -. Auch in anderen Programmiersprachen, wo die Auswirkungen sind „nur“ auf visueller Ebene

Imho, der wichtigste Punkt, dass die meisten (wenn nicht alle) Antworten hier fehlen, ist die Interaktion zwischen den Teams oder Einzelpersonen, vor allem in Situationen, in denen die Teilnehmerliste ist nicht zu Beginn wissen. Wenn Code Code trifft entweder haben alle Registerkarten verwenden oder alle Leerzeichen verwenden. Es kann nicht gemischt werden, ohne schließlich in Funktionalität Probleme läuft. Menschen sind nicht perfekt. Werkzeuge sind nicht perfekt. Deshalb imho sollten wir nicht TABs überhaupt.

Keine Antwort ist komplett ohne den Link, dass Greg in seiner Antwort zur Verfügung gestellt schon: Python: Mythen über Einrückungen

Jeder hat andere Vorlieben, wie viel Code sollte vertieft werden. Angenommen, Sie Code mit jemandem teilen und er oder sie unterschiedliche Präferenzen in Bezug auf Einbuchtung hat. Wenn die Vertiefungen in Tabs sind, kann Ihr Freund immer nur die Tabulatorbreite Einstellungen in ihren Editor ändern. Wenn jedoch die Vertiefungen in den Räumen sind, Ihr Freund muss tatsächlich den Quellcode ändern, wenn er oder sie es zu ihrer Präferenz festlegen möchten. Dann, wenn Sie Ihre Freundin Änderungen zu erhalten, können Sie entscheiden, es zurück zu Ihrer Präferenz zu ändern. In diesem Fall müssen Sie entweder mit dem Langwierigkeit Ebenen der Veränderung Vertiefung behandeln hin und her, oder einer Person muss die anderen Präferenzen in Einrückungsebene nehmen. Wenn Sie und Ihr Freund Tabs verwenden, die Tatsache, dass Sie unterschiedliche Präferenzen haben, ist kein Thema, wie Sie jeweils verschiedene Einrückungen zu sehen, während der Code unverändert bleibt. Deshalb, meiner Meinung nach, Tabs sind besser als Räume für Vertiefung in allen Programmiersprachen.

Es gibt ein Szenario, in dem Registerkarten einfach, nämlich nicht funktionieren: Je nach Art der Programmierung Sie verwenden, Sie könnten einige Zeilen Code zu einem Raum Genauigkeit einrücken müssen, das heißt:

def foobar():
    x = some_call(arg1,
                  arg2)

In diesem Fall wird lediglich Tabs nicht funktionieren; mit Registerkarten für Haupt Einzug und Räume für Untergedankenstrich wird funktionieren, aber die harte Regel nicht die beiden Misch verletzen.

Dies ist der Fall jedoch nicht sein, wenn eine Codierungsstil / Konventionen Dokument verwenden, die Situationen wie in dem obigen Codebeispiel vermeidet.

Das Problem bei Verwendung von Leerzeichen anstelle von Tabulatoren ist die Dateigröße so unglaublich groß wird ... Zum Beispiel kann eine 500 KB Raum gegliederte Datei auf 200 KB reduziert werden könnte, wenn Räume für Tabs Swapping, weshalb ich immer Registerkarten .

Kleinere Datei-Größe bedeutet schnelleres Laden, Kompilierung, Ausführung (in einigen Fällen), etc.

Für mich gibt es keinen Punkt Räume zu verwenden, aber wenn jemand einen Editor verwendet, die Probleme mit Registerkarten, dann können sie „\ t“ mit „“ oder „“ oder was auch immer ersetzen ...

Zusätzlich zu allen Argumenten bereits aufgeführt, finde ich dies eine ziemlich wichtig (von Mythen über Einbuchtung ):

  

Auch oft Tabs zerstört oder falsch während Copy & Paste-Operationen umgewandelt, oder wenn ein Stück des Quellcodes in eine Webseite oder eine andere Art von Markup-Code eingefügt wird.

Ein weiteres Argument (stark umgebungsspezifischen, obwohl) gegen Registerkarten ist, dass sie sind manchmal am Telefon Tastaturen fehlen. Dies könnte wahrscheinlich durch die Installation eine alternative Tastatur behoben werden, soweit möglich.

Ein Argument Laschen, die noch niemand zu haben schien erwähnt ist, dass 1 tab 1 Zeichen ist (0x09, 1 Byte in der Datei), während 4 Leerzeichen sind 4 Zeichen (4-mal 0x20, 4 Bytes in der Datei); also die Verwendung von Leerzeichen Ergebnissen in einer 4-fach Platzverschwendung.

Mit dieser inkohärente Liste der Argumente Abschließend möchte Ich mag Tim Peters zitieren Antwort in der Ausgabe 7012: Tabs ist besser als Leerzeichen für die Einrückung :

  

Der Python „Räume nur“ Standard ist für   verteilt Code. Jahre der frühen Erfahrung hat uns gelehrt, außer Zweifel, dass   Tabs verursacht endlose Probleme für shared Code (...)

  

Wie funktioniert das einen Unterschied machen?

Einige Editoren sind standardmäßig konfiguriert, um einen Tabstopp mit einer bestimmten Anzahl von Leerzeichen zu ersetzen, aber manche nicht. Wenn alle Räume verwendet, kann dieser Unterschied in der Standard-Editor-Einstellungen ignoriert werden.

  

Gibt es andere Gründe, warum ein Leerzeichen anstelle von Tabulatoren für Python verwenden würde? Oder ist es einfach nicht wahr?

Ja, es gibt noch andere gute Gründe, wie viele Antworten vor mir aufgezeigt. „PEP-8“, sagt so, aber nicht einer dieser Gründe ist. Dies ergibt sich aus dem Selbst verewigen Mythos, dass PEP-8 ist die Codierung Standard für alle Python-Code, wenn in der Tat ist es nur die Kodierungsstandard für den Standardsatz von Python-Bibliotheken. Einige behaupten, dass PEP-8 ist weithin anerkannt, und einige behaupten, dass die meisten Python-Programmierer Leerzeichen verwenden anstelle von Tabulatoren. Ich möchte für Beweise dieser Ansprüche stellen, da die Anzahl der Stimmen auf dieser Seite zeigt deutlich, dass Laschen durch die Massen bevorzugt. Ich finde es sehr bedauerlich, dass Sie „PEP8 sagt so“, wie die Antwort auf Ihre Frage angenommen haben, wenn in der Tat gibt es viele andere Antworten gibt, die tatsächlich die relativen Vor- und Nachteile von Leerzeichen und Tabulatoren erklärt.

  

Soll ich wechsle mein Editor Leerzeichen statt Tabs direkt einfügen oder weitermachen wie früher?

Es hängt davon ab, und die Antwort auf diese letzte Frage ist, wo ich dachte, dass ich tatsächlich etwas Wert auf diesen Thread hinzufügen könnte. IMHO, unabhängig von der verwendeten Sprache, der beste Codierungsstandard zu verwenden, hängt von der Situation, die Sie befinden sich in:

  • Wenn Sie auf einem bereits bestehenden Code-Basis zu arbeiten begonnen: nicht schwierig sein, folgen Sie dem vorhandenen Codierungsstandard
  • Wenn ein Team an einem neuen Projekt von Grund auf neu ist: diskutieren, auf einem Codierungsstandard am Anfang als Team entscheiden, und dabei zu bleiben
  • Wenn Sie solo gehen: tun, was das macht Sie fühlen sich die glücklichsten und die produktivste

So, die Situation fallen Sie unter?

Schließlich meine Haltung klar, für meine eigenen Soloprojekte zu machen, verwende ich Tabs weil Tabs mehr Sinn für mich, und ich bin produktiver mit Tabs.

Ich glaube, dass es eine Lösung gibt, beides zu haben:

  1. Kompatibilität mit PEP-8 und der Verwendung von Leerzeichen
  2. Bequemlichkeit der Verwendung von Tab anstelle von 4 Leerzeichen
go

In Notepad ++, die auf „Einstellungen“ -> „Einstellungen auf der Registerkarte“ und wählen Sie „Python“ aus der Liste auf der rechten Seite. Dann stellen Sie sicher, „Tab Größe: 4“, und das Kontrollkästchen „ersetzen [Tab] durch den Raum“. In diesem Fall können Sie einfach mit der Tabulatortaste einrücken, aber Notepad ++ eigentlich, dass für Sie 4 Räume verwandeln.

Dies ist PEP 8 ab Juli 2017:

Es scheint diese Aussage nicht Raum für eine andere Wahl nicht verlässt.

Das ist aber nicht allein, was PEP 8 sagt uns, einige Zeilen später:

In der obigen, die erste Aussage drückt eine Präferenz für Räume und die zweite Erklärung erkennt die Existenz von Code eingekerbt mit Tabs und diese Vorliebe für einige Programmierer.

So : PEP 8 Tab Einbuchtung tolerant. Es duldet keine Tab und Raum für Vertiefung gemischt obwohl, die, da selbst Einrückungen obligatorisch ist, ist verständlich.

Es kann sich lohnen, zu erwähnen, dass Googles Python Codierstil folgt auch die 4-Raum-Regel.

Es gibt andere verschiedene Argumente und Begründungen für entweder Tabs oder 4-Raum.

Wenn Sie in einem Unternehmen arbeiten, die PEP erzwingen 8 oder Code regelmäßig mit anderen teilen, die PEP folgen 8, dann der gesunde Menschenverstand diktiert 4-Raum. Ich bin (war vielleicht) verwendet, um Tabs von C / C ++. Aber mit einer richtig eingestellt IDE, die Differenz minimal wird.

Benutzen Sie Leerzeichen anstelle von Tabulatoren, aus dem einzigen Grund, dass Sie mehr Geld verdienen:)

Ref .: Entwickler Wer Spaces verwenden Machen Sie mehr Diejenigen Geld als Wer Tabs verwenden (Stack-Überlauf Blog-Post).

Also hier lese ich alle Antworten und frag mich, wie ich mit PEP-8 ohne Ärger Stampfen meine Rücktaste nur immer wieder erfüllen kann Einzug zu entfernen, und ich sehe mein Logitech Gaming-Tastatur mit all seinen ausgefallenen Makro-Tasten nach unten und eine Glühbirne leuchtet in den Kopf.

Ich öffnete Logitechs Software, definiert direkt neben ein paar Makros für die Schaltflächen auf der Registerkarte Schaltfläche, und das Problem ist gelöst.

Eine Taste fügt vier Räume, und der andere tut Backspace viermal. Tolle. Einfach unglaublich. So einfach, die Tasten mit meinem kleinen Finger zu schlagen, auch.

Sehen Sie, check this out:“„<- vier Räume! Mit einem Knopfdruck! Wenn ich Ihnen die Rücktasten zeigen könnte, würde ich das auch tun. Gehen Sie eine Logitech G105 Tastatur erhalten und alle Ihre Probleme gehen weg!

Ich bin gerade erst anfangen, aber ich finde es viel einfacher Tabs zu verwenden, als Räume, und nicht verstehen, die PEP-8 advocation von Räumen nur. Sublime Text 2 hat eine große Aufgabe der Registerkarten mit der Off-weißen vertikalen, gepunkteten Linie zu visualisieren und während es Fällen von mir einen Raum oder zwei Mischelemente einer Liste oder Wörterbuch aufreihen, ich habe keine Situation erlebt, wo das würde schädlich sein Ding.

Ich liebe Tabs, aber es ist irgendwie nicht kompatibel mit einer anderen Regel Ich mag:. Die 80 Spalt Grenze

Wenn man wählt, 4 Leerzeichen Registerkarten und fügt 10 Tabletten, dann gibt es Platz für 40 Zeichen zur Verfügung, um die 80-Säule Grenze zu erfüllen. Wenn ein anderer Codierer 8 Leerzeichen Registerkarten vorzieht, wird die gleiche Zeile wie 120 Zeichen lang erscheinen und nicht als gültige 80 Spalten Zeile erscheinen!

Wenn Sie eine 80-Säule Grenze definieren wollen, dann müssen Sie eine Länge für eine Registerkarte wählen. In diesem Fall mit x Leerzeichen oder eine Registerkarte mit der Länge x macht nicht wirklich einen Unterschied.

Edit: Verwandte thread: pflegen Maximale Zeilenlänge Bei Verwendung von Tabs statt Leerzeichen?

Ich denke, einer der Hauptvorteile der Verwendung von Leerzeichen besteht darin, dass Sie die Variabilität bei der Darstellung Ihres Quellcodes durch die Vielzahl externer Tools beseitigen, die über den Editor Ihrer Wahl und die von ihnen konfigurierten Einstellungen hinaus mit der Quelle interagieren müssen.

Als einige konkrete Beispiele betrachten wir das Rendern von Python-Dokumentzeichenfolgen in einem Tooltip in Visual Studio-Code, oder in einem Diff-Tool wie Unvergleichlich oder WinMerge, Leistungs- oder Codeabdeckungstools usw.Grundsätzlich können alle diese verschiedenen anderen Schnittstellentools jeweils unterschiedliche Einstellungen für die Interpretation von Tabs haben, und es kann ärgerlich und manchmal verwirrend sein, wenn bei den Toolsets, in die Sie eintauchen und aus denen Sie heraustauchen, Dinge völlig unterschiedlich oder weit außerhalb des Bildschirms verschoben sind.

Kurz gesagt, Sie definieren die Ausrichtung in der Quelle, anstatt eine einheitliche Konfiguration für die Suite von Tools in Ihrem Arsenal festzulegen.Leerzeichen werden in einer Monospace-Schriftart strikt interpretiert, um aufgrund der Definition der Schriftart und nicht der Implementierung/Konfiguration der Tab-Rendering-Implementierung/-Konfiguration eines Drittanbieters eine zuverlässige und konsistente Ausrichtung über die gesamte Werkzeugspanne hinweg zu gewährleisten.

Ein weiterer Aspekt besteht darin, führende Tabulatoren aus der Quelle zu kopieren, um sie auf einem Terminal auszuführen, wo das Tabulatorzeichen eine unbeabsichtigte Tabulatorvervollständigung auslösen kann.Wenn Sie beispielsweise die folgende Python-Quelle kopieren (Tabulatoren werden als Einrückung verwendet),

cmd_create_db = '''CREATE TABLE test (
    Col1 INTEGER,
    Col2 INTEGER,
    Col3 TEXT)'''

Möglicherweise sehen Sie etwas wie das Folgende (zu sehen im integrierten Terminal von Visual Studio Code) ...

>>> cmd_create_db = '''CREATE TABLE test (
... .DS_StoreCol1 INTEGER,
... .DS_StoreCol2 INTEGER,
... .DS_StoreCol3 TEXT)'''
>>> cmd_create_db
'CREATE TABLE test (\n.DS_StoreCol1 INTEGER,\n.DS_StoreCol2 INTEGER,\n.DS_StoreCol3 TEXT)'

(Beiseite:Ich habe mich gefragt, ob diese Beobachtung der Konsistenz über alle Tools hinweg ein Zeichen für den scharfsinnigen Verstand eines scharfsinnigen Entwicklers ist, der die Welt ordnen will, und vielleicht ein Hinweis auf die Gehaltsunterschiede bei Stack Overflow ist.)

Ich verwende zwei Raum Vertiefung und ein Editor (kwrite), die Leerzeichen anstelle von Tabulatoren einfügt, wenn ich die Tab-Taste getroffen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top