Was sind die Nachteile von elastischen Tabstops? [geschlossen]


83

Schauen Sie hier: Ein typischer heiliger Krieg zwischen Tabs und Leerzeichen .

Schauen Sie jetzt hier: elastische Tabstops . Alle Probleme wurden gelöst und eine Reihe sehr nützlicher neuer Verhaltensweisen hinzugefügt.

elastische Tabstops

Werden elastische Tabstops in der Diskussion zwischen Tabs und Leerzeichen überhaupt erwähnt? Warum nicht? Gibt es Nachteile bei der elastischen Tabstop-Idee, die so gravierend sind, dass niemand sie jemals in einem beliebten Editor implementiert hat?

EDIT : Ich entschuldige mich dafür, dass ich zu viel Wert auf "Warum werden sie nicht erwähnt" lege. Das war nicht wirklich das, was ich beabsichtigt hatte; Diese Frage ist möglicherweise sogar vom Thema ab. Was ich wirklich meine ist, was sind die größten Nachteile davon, die eine weitere Übernahme einer offensichtlich vorteilhaften Idee verhindern? (In einer idealen Welt, in der alles schon alles unterstützt)

(Es hat sich herausgestellt, dass in Microsoft Connect bereits eine Anfrage nach einer Visual Studio-Implementierung von elastischen Tabstops und auch in Eclipse vorliegt . Außerdem werden Fragen zu anderen Editoren gestellt, die elastische Tabstops implementieren. )


4
Dies wäre eine großartige Frage für ux.stackexchange.com
JonnyBoats

11
Sie werden in der Diskussion "Tabs versus Spaces" nie erwähnt, weil es für einen arbeitenden Programmierer so gut wie keine Möglichkeit gibt, diese Dinge zu verwenden. Wenn Sie eine Eclipse-, VS-, gvim- und emacs-Implementierung hätten, könnte sich dies möglicherweise ändern.
Paul Tomblin

2
Die Idee gefällt mir sehr gut, aber nur, wenn Sie einen Monat lang damit leben, wissen Sie wirklich , was die Tücken sind. Wie immer gibt es garantiert einige Fälle, in denen es Dinge tut, die Sie nicht erwarten würden ...
Chris Burt-Brown

3
@ ChrisBurt-Brown Das ist ja immer ein Risiko. IntelliSense hat auch seine Tücken, wie das Unterteilen von Text, wenn Sie es nicht wollten. Insgesamt ist IntelliSense in C # jedoch ein großer fetter Gewinn.
Roman Starkov

4
Ich möchte dies im Editor ++ ... Ich möchte dies jetzt
Ben Brocka

Antworten:


32

Heilige Kriege sind subjektiv

Nicks elastische Tabstops sind ein erstaunliches Konzept , das vielen Leuten helfen könnte, sich auf eine praktikable Lösung zu einigen, obwohl ich sehr bezweifle, dass es diesen Heiligen Krieg gänzlich beenden würde: Es ist schließlich auch eine Frage des Geschmacks und viele Programmierer werden sich nicht bewegen Zoll von ihrer Position in dieser Angelegenheit, auch auf Kosten des Kompromisses. Das wäre also ein erster Grund.

Zum Beispiel werden es viele Leute auf der Seite "Leerzeichen" immer noch nicht mögen, da es ein zusätzliches Stück Logik in Ihrer Software für ein anständiges Rendern erfordert (z. B. einfaches Anzeigen eines Änderungssatzes in der Webansicht Ihres SCM).

Umsetzungsfragen

Aber der offensichtlichste Grund ist nur seine technische Barriere für den Eintritt : es ist ein grundlegend anderes Konzept von dem, was für eine Reihe von Jahren umgesetzt wurde (wenn nicht Jahrzehnte) in IDEs und Texteditoren. Einige von ihnen müssten neu geschrieben werden, um Zeilen in einer anderen Fasion zu verarbeiten. Dies erschwert es älteren und größeren Systemen, bei denen die Wahrscheinlichkeit einer tiefen und engen Kopplung im Zeilenverarbeitungscode höher ist. Es ist jedoch viel einfacher, wenn Sie bei Null anfangen (denken Sie an Nicks Demo oder an Go 's Tabwriter- Paket).

Als persönliche Anekdote erinnere ich mich, dass ich mich vor einiger Zeit an den Autor gewandt habe, um ihn zu fragen, ob Unterstützung für den Emac in Sicht war. Er bat auch die Community um Hilfe, um dieses Feature zu implementieren und der Masse zugänglich zu machen.

Kümmern wir uns genug?

Ein dritter Grund ist, dass einige Entwickler nicht so aufgelegt sind und sich nicht so sehr darum kümmern, dass sie sich die Mühe machen würden, die Bemühungen zu unterstützen. In den meisten Fällen ist der Konflikt zwischen Leerzeichen und Tabulatoren kein Business-Blocker.

Wenn du es willst, musst du dafür kämpfen. Was in Open-Source-Software machbar ist. Und wenn Sie genug davon ändern, müssen Closed-Source-Produkte auf die Gefahr folgen, einen Teil ihrer Nutzerbasis zu verlieren, wenn ein noch so kleiner Teil davon.

Also, wenn du willst, hilf Nick.


(Off Topic) Ich frage mich oft, wie andere "Das ist nett, aber sehr geringfügig" -Funktionen es jemals in Produkte wie Visual Studio geschafft haben. Es scheint, dass jemand im Team einfach aus persönlichen Gründen die Zeit gefunden hat, dies umzusetzen. Stellen Sie sich beispielsweise vor, Sie geben in Visual Studio mehrere Zeilen gleichzeitig ein . Es ist nicht so, als ob Zehntausende danach gefragt hätten, aber ich mag es lieber.
Roman

3
@romkyns: Wie bei vielen Dingen braucht es entweder einen leisen Insider oder tausend Stimmen, die vor den Toren schreien.
Haylem

35

Oft musste ich mit einem Textverarbeitungsprogramm kämpfen, damit das Dokument so aussah, wie ich es wollte, ohne dass eine versteckte automatische Regel die Platzierung meiner Wörter kontrollierte. Ich möchte nicht eine Sekunde damit verbringen, herauszufinden, warum der Herausgeber darauf besteht, diese Wörter dort zu platzieren.


11
Ich sympathisiere auch nicht voll mit diesem Gefühl, da mich solche Regeln auch wirklich frustrieren. Dies ist jedoch in zweierlei Hinsicht unterschiedlich. Erstens: Genau wie jetzt Tabstops müssen Sie sie nicht verwenden, wenn Sie nicht möchten. Sie können den Text Ihrer Kollegen in Ruhe lassen, wenn er sie verwendet. Zweitens: Bei elastischen Tabstops gibt es keine versteckten, sondern nur offensichtliche Regeln. Das Verhalten ist völlig natürlich - vielleicht sogar natürlicher als herkömmliche Tabstopps, die an einer beliebigen, normalerweise irrelevanten Stelle im Text auftreten. Aus diesem Grund verwendet niemand mehr Tabstopps für etwas anderes als Einrückungen.
Timwi

10
@ Timwi: Die Frage war, Nachteile aufzuzählen. Ich tat.
mhoran_psprep

14
Aus dem GIF ist es möglicherweise nicht ersichtlich, aber das einzige Problem besteht darin, dass beim Drücken der Tabulatortaste das, was danach kommt, richtig vertikal ausgerichtet ausgegeben wird. Es ist nichts wie ein Textverarbeitungsprogramm. Probieren Sie einfach die eigentliche interaktive Demo unter dem von mir geposteten Link aus und Sie werden sehen, wie natürlich es ist.
Roman Starkov

3
@mhoran_psprep: Fair genug, ich schätze Ihre Eingabe. Ich denke, wir haben uns verschiedene Interpretationen der Frage angesehen. Sie listen die Nachteile Ihrer Nutzung der Funktion auf, während ich dachte, es handele sich um Nachteile bei der Einführung der Funktion (dh um die Bereitstellung und nicht zwingend vorgeschriebene ).
Timwi

27

Dies ist das erste Mal, dass ich davon hörte. Ich bin mir nicht sicher, ob sie eine gute Idee sind, aber sie scheinen wenig nützlich zu sein, da wir Werkzeuge (wie Einrückungen) haben, die Code bereits automatisch formatieren.

Was passiert, wenn ich Ihre cleveren elastischen Tabstops in Vim öffne und bearbeite? Bereinigt sich der Tab automatisch oder bleibt ein Durcheinander zurück?

Die Hauptnachteile, wie ich sie sehe, sind möglicherweise das Brechen von Diffs, die Versionskontrolle und die Unverträglichkeit mit Editoren, die sie nicht unterstützen. Möglicherweise ist es eine Menge Code-Modifikation, um sie zu unterstützen, und es gibt wichtigere Dinge als die Funktion "Noch eine Tab-Sache, um Code zu formatieren". Schließlich können wir alle verwenden, indentwas alles oben genannte tut, wenn der Speicher dient.


9
Was für eine rückwärts denkende Haltung. Lasst uns keinen Fortschritt machen, weil die alten, veralteten Lieblingswerkzeuge der Leute noch nicht damit fertig werden ! (Die Ironie ist natürlich, dass diese Tools (wie vim) Open Source sind. Wenn es für Sie also wirklich wichtig wäre, könnten Sie (und sollten Sie wahrscheinlich ) elastische Tabstop-Unterstützung hinzufügen.)
Timwi

14
@ Timwi: Sie vermissen den Punkt, den ich gemacht habe. Was passiert, wenn Ihre Codedatei von etwas analysiert wird, das elastische Tabstopps nicht kennt? Kommst du in ein Chaos oder kommen sie zurecht? Was ist mit der Versionskontrolle und den Unterschieden? Nur zu wünschen, dass alle Tools $ -Feature unterstützen, ist unrealistisch, selbst wenn diese Tools Open Source sind.
Sardathrion

14
@ Timwi: Sie gehen davon aus, dass jeder elastische Tabstops so toll findet, wie Sie denken. Dies kann nicht wahr sein.
Sardathrion

7
@Sardathrion ist richtig. Was passiert, wenn ich einen Remote-Zugriff auf meinen * nix-Server ohne Fenstersystem ausführen und Code mit Vim / Emacs / Pico / Whatever untersuchen muss? Wenn es einen Mechanismus gibt, der lesbar ist, wäre das in Ordnung ... sonst wäre es ein Albtraum. Ich sehe nicht, dass der Vorteil von elastischen Laschen sowieso so vorteilhaft ist. Ich kann meinen Code bereits automatisch formatieren, um zu sehen, wie er in den von mir verwendeten IDEs aussehen soll.
Rig

7
Der Versionskontrollpunkt ist gut - ich glaube nicht, dass die Leute einen Editor schätzen werden, der stillschweigend beginnt, die Platzierung / das Format von Kommentaren im Code zu ändern, und zwar beliebig weit entfernt von dem Code, den sie ändern (siehe Abschnitt Magenta in den animierten OPs) gif). Es wäre hilfreich, eine Referenzimplementierung zum Spielen zu haben, aber was ich bisher sehe, ist nicht bemerkenswert - Emacs macht bereits viel davon, nur mit ein paar zusätzlichen Tastenanschlägen (was wohl eine gute Sache ist).
mcmcc

13

Um ehrlich zu sein, finde ich sie nicht so nützlich, wenn Sie die anfängliche Aufregung überwunden haben. Zum Beispiel mag ich sowieso keine Kommentare am Ende einer Zeile - ich setze meine Kommentare immer in eine separate Zeile. Dadurch verlieren elastische Laschen ihre Hauptverwendung.

Danach können Sie sie natürlich weiterhin zum Ausrichten von Funktionsargumenten (und Parametern) und langen Zuweisungslisten verwenden.

Aber für die erstere neige ich dazu, alle Argumente nur um eine zusätzliche Ebene einzurücken, und das funktioniert bei mir ganz gut:

void foo(
    int x,
    int y,
    string z
)

Und ich sehe keinen Grund, das zu ändern.

Und was das Ausrichten von Aufgaben angeht, mache ich das nicht. Ich setze einzelne Leerzeichen um Aufgaben, das war's. Ich neige auch dazu, viele Aufgaben nicht zu gruppieren, so dass es selten irgendwelche Lesbarkeitsprobleme gibt.

Zusammengefasst haben elastische Zungen absolut Null Nutzen für mich. Dies ist natürlich eine sehr persönliche Präferenz, die variieren kann, aber ich finde, dass sie gut funktioniert und ich denke, dass der Mangel an Unterstützung für elastische Laschen darauf zurückzuführen ist, dass andere Leute ähnlich denken.

Wenn ein Editor sie implementieren würde, würde ich sie immer noch nicht verwenden.


Geschätzt. Es sieht so aus, als könnten Sie auch gerne eine Schriftart mit variabler Breite verwenden, wenn Sie nur möchten, da Sie ohnehin nichts anderes als den Zeilenanfang ausrichten. Visual Studio unterstützt dies ziemlich gut, und die Verbesserung der Lesbarkeit ist gut.
Roman Starkov

1
@romkyns Wir hatten Diskussionen darüber und im Laufe einer habe ich einige Zeit versucht, eine proportionale Schriftart für die Programmierung zu verwenden. Das Ergebnis war, dass monospaced Schriftarten besser funktionieren, auch wenn die Einrückung nicht berücksichtigt wird. Abgesehen davon arbeite ich derzeit ausschließlich in Vim und der Konsole, von denen wahrscheinlich keine Proportionalschriftarten unterstützen wird.
Konrad Rudolph

1
@romkyns Das heißt, diese Probleme sind lösbar (oder vielleicht sogar gelöst, mit einer proportionalen Schriftart für die Programmierung). Aber ich sehe die Notwendigkeit immer noch nicht wirklich.
Konrad Rudolph

13

Ein Nachteil ist, dass es nicht funktioniert, wenn Sie die Ausrichtung in einer Gruppe von Zeilen und dann die Einrückung in der nächsten Gruppe möchten, da die Tabulatoren benachbarter Zeilen gruppiert werden.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Was ich wollte:

def foo( bar,
         xyzzy ):
    wibble()

Bei Sprachen mit geschweiften Klammern ist dies möglicherweise weniger problematisch, da Sie dies normalerweise lösen können, indem Sie die öffnende Klammer in eine eigene Zeile setzen (wie in der Animation). und am Ende müssen Sie auf die Verwendung von Leerzeichen zurückgreifen.


Einverstanden. Nicks Implementierung funktioniert für Sprachen wie Python überhaupt nicht sehr gut.
Roman Starkov

3
Warum würde das nicht funktionieren? Dies ist keine grundlegende Einschränkung, der Algorithmus muss nur sprachbewusst sein. Bis zu einem gewissen Grad gilt dies auch heute noch. So definiert Vim je nach Sprache unterschiedliche Einrückungsregeln. Dies könnte leicht Python-Einrückung aufnehmen.
Konrad Rudolph

1
@KonradRudolph Nein, das konnten sie nicht. Das Ziehen von elastischen Tabstopps ist die Fähigkeit, Textgruppen automatisch zusammenzuziehen / zu entfernen. Ein einfaches Beispiel ist das Ende einer "if" -Anweisung: Sie versuchen, die Einrückung aufzuheben, weil Sie die Anweisung verlassen, aber die "intelligenten" elastischen Tabstopps entscheiden, dass Sie beabsichtigen, die Einrückung der ein oder zwei Zeilen usw. aufzuheben und so weiter ... Und wenn Sie Text explizit gruppieren müssen, was ist dann der Sinn? Es ist mehr Arbeit, das zu tun, als die Einrückungen selbst zu reparieren ...
Izkata

1
@Izkata Manuelles Aufheben der Einrückung würde (sollte) einfach die aktuelle Gruppe beenden. Warum sollten Sie die Einrückung jemals manuell mit den elastischen Anschlägen steuern? Sie würden es nicht tun, daher weiß der Algorithmus, dass es bei diesem Vorgang darum geht, einen Block zu beenden und den obigen Block nicht rückgängig zu machen.
Konrad Rudolph

1
Oh, guter Punkt. Hmm ... vielleicht könnten Sie die Argumente doppelt einrücken? Hätte man dann wibble()nur eine einzige Einrückung und wäre daher nicht an den Funktionsargumenten ausgerichtet?
Ajedi32

12

Warum lassen wir nicht einfach das vertikale Tabulatorzeichen (VT, ASCII 11) als Hinweis auf die Verwendung von elastischen Tabulatoren dienen? Es hat in keiner der gängigen Programmiersprachen einen Zweck , wird jedoch in allen von ihnen, AFAIK, als gültiges Leerzeichen analysiert.

Dies würde bedeuten, dass die Verwendung von elastischen Tabstops keine externe Konvention mehr ist (z. B. "Diese Datei wurde mit elastischen Tabstops formatiert, bitte aktivieren Sie sie"), sondern etwas, das Sie von Fall zu Fall auswählen.

In vorhandenen Texteditoren wird in der Regel anstelle eines vertikalen Tabulators eine Glyphe oder ein einzelnes Leerzeichen angezeigt. Dies ist nicht ideal, aber ein kleiner Preis zu zahlen, IMO.


10

Sie werden nicht erwähnt, da sie in den meisten IDEs von Texteditoren nicht implementiert sind. Sie sind eine Neuheit, die in einem Projekt kaum wirklich Verwendung findet.

Seit den Tagen der Lochkarten wurden Leerzeichen verwendet, um die Programmierung zu gestalten. Tabs kamen und jemand hielt sie offensichtlich für eine gute Idee (sie täuschten sich: p).

In den Tagen, in denen die meisten modernen Editoren Tabulatoren automatisch in Leerzeichen konvertieren können, sind sie ziemlich sinnlos.

Ein weiteres Tool installieren zu müssen, um mit etwas so Trivialem wie Tabs vs.


Ich habe die Kommentare gelöscht, als sie zu einer Beleidigung wurden.
ChrisF

1
Ich wollte nur darauf hinweisen, dass der Hauptgrund, warum ich die Idee elastischer Tabstops mag, nicht darin liegt, dass das Problem zwischen Tabs und Leerzeichen gelöst wird, sondern in dem Verhalten, das im GIF in der ursprünglichen Frage gezeigt wird. Automatische, schmerzfreie Ausrichtung. Für VCS-Unterschiede gibt es außerdem den zusätzlichen Vorteil, dass in diesem Beispiel keine Leerraumänderungen erforderlich waren.
Ajedi32

"Noch ein Werkzeug installieren zu müssen ..." ist kein gutes Argument ... Als ob es nicht genug Werkzeuge gibt, die bereits verwendet werden.
Milind R

@MilindR Ob Sie es für gut genug halten oder nicht, es ist der Grund, warum ich (vor drei Jahren) kein Interesse daran hätte. Viele Tools, die etwas Nützliches bewirken, sind kein Grund, ein weiteres Tool hinzuzufügen, das Ihrer Umgebung wirklich nichts hinzufügt.
TZHX

Einstellungen wie diese sind der Grund, warum Unternehmen wie MS Benutzer zu neuen UXs zwingen ... Ich schaudere bei der Überlegung, was passieren würde, wenn dieselbe Einstellung auf die Disketten angewendet würde -> CD-Übergang.
Milind R

4

Ich denke, dass sie viel Nutzen finden würden, wenn IDEs sie unterstützen würden (Microsoft!). Sobald die Leute herausgefunden haben, dass sie ihre Blumenkästen auf die Seite schlagen und sie gut lesbar haben, werden sie es tun. Möglicherweise werden plötzlich mehr Kommentare zum Quellcode hinzugefügt (was nur eine gute Sache sein kann).

Ich nehme an, wir könnten der Liste "Wäre es gut, wenn ..." auch "Tooltips" für Kommentare hinzufügen, damit Ihre großen Kommentarblöcke bei Bedarf einfach ausgeblendet und angezeigt werden können. Möglicherweise könnten wir auch Kommentarblöcke haben, die Teil der Dokumentation sind (keine Sandburg-artigen Inhalte, korrekte, vom Benutzer lesbare Dokumentationsschnipsel, die in den Code eingebettet waren, nicht nur die Methodenköpfe).

Nachteile: Es kann dazu führen, dass Ihre Quelldifferenzen schlecht aussehen, wenn ein paar Zeilen so aussehen, als wären sie geändert worden, als wirklich nur 1 geändert wurde (wenn der Editor die Datei mit den in Leerzeichen konvertierten Registerkarten gespeichert hat). Wenn der elastische Tabulator mit einem einzelnen Zeichen implementiert wurde (oder eher mit 2 Tabulatoren), kann die Anzeige Ihrer Quelle außerhalb des Editors schlecht aussehen.

Ich denke, die Idee gefällt mir, 'Tabulator Tabulator' am Ende einer Zeile macht den Kommentarblock elastisch und richtet alle Kommentare in nachfolgenden Zeilen (die den doppelten Tabulatorabstand haben) entsprechend aus.


3

So sehe ich das: Wenn die meisten gängigen Tools bereits elastische Tabstops unterstützen würden, würden viele Leute sie verwenden. Dasselbe geschah mit dem Navigations- / Bearbeitungsmodus von vi, mit Syntaxhervorhebung und später mit Intellisense. In jedem Fall war die etablierte Weisheit, dass es nicht nützlich ist oder nicht benötigt wird, aber es wurde implementiert und es ging los.

Elastische Tabstops haben natürlich eine relativ geringe Auswirkung. Die meisten Menschen sind mit dem Status quo zufrieden und interessieren sich daher nicht dafür. Eine ähnliche Überlegung wird auf viele Situationen angewendet, in denen manche Menschen nur mit dem zufrieden sind, was sie haben, und keinen Grund sehen, auf etwas Fortgeschritteneres umzusteigen. Mit anderen Worten, das größte Problem bei elastischen Tabstops ist dasselbe wie bei fast jeder anderen guten Idee: Sie müssen an Bodenhaftung gewinnen.

Dies bedeutet jedoch nicht, dass die Funktion nicht schrittweise übernommen werden kann. Jede einzelne Programmiersprache wurde schrittweise übernommen, obwohl ein ganzes Team einen neuen Compiler und eine neue IDE benötigt, um sie zu verwenden. Gleiches gilt für jede einzelne Hardwarearchitektur und viele weitere Beispiele. Es ist auch nicht der Fall, dass die mangelnde Integration in vorhandene Tools ein Show-Stopper ist: Dies gilt beispielsweise auch für das „Unified-Diff-Format“, das ein früher weniger lesbares Format, das von automatisierten Tools dennoch verstanden wurde, schrittweise ersetzte (wie Patch). Diese Tools wurden im Laufe der Zeit aktualisiert.

Ich schätze die Interop-Probleme, die andere angesprochen haben, aber trotz alledem wird es sicherlich Teams (wie meine) geben, die dies in unserer Gesamtheit ohne zu zögern übernehmen würden. Externe Tools wie Vergleichen, Zusammenführen usw. unterstützen dies zunächst nicht. Wir würden jedoch unseren Teil dazu beitragen, die Anbieter zu ermutigen, die Funktion einzuschließen. So wurden immer Fortschritte erzielt. Es erfordert einige Schmerzen für eine vorübergehende Übergangszeit, aber am Ende lohnt es sich.


Das C vs C ++ Argument scheint ein bisschen fehlgeleitet. Es mag zwar zutreffen, dass dies bei "einigen Leuten" der Fall ist (wie Sie zu Recht sagten), aber es gibt offensichtliche Gründe, je nach Situation an C festzuhalten oder C ++ zu bevorzugen. Die Größe der C ++ - Laufzeit ist in der Standardeinstellung eine davon.
Haylem

Ich bin bei Haylem. Ohne den C-versus-C ++ Vergleich wäre Ihr Punkt mehr Klang. Das sind ganz andere Sprachen. Meiner Meinung nach ist C für die Systemprogrammierung und andere Arbeiten auf niedriger Ebene gedacht, bei denen Sie viel Kontrolle benötigen (z. B. eine VM). C ++ eignet sich eher für Anwendungen auf mittlerer Ebene, bei denen die Abstraktion hilfreich ist, um die Komplexität zu verwalten (Namespaces, STL-Container und -Algorithmen, Vorlagen), die Leistung jedoch weiterhin ein Problem darstellt (Spiele sind das sichtbarste Beispiel).
Jon Purdy

@haylem: Danke für das Feedback. Ich habe den Verweis auf C / C ++ entfernt.
Timwi

@ JonPurdy: Danke für das Feedback. Ich habe den Verweis auf C / C ++ entfernt.
Timwi

2

Das größte Problem, das ich damit hätte, ist der inkonsistente Abstand in der gesamten Dokumentation. Ich weiß, dass ich mich als Programmierer ärgern würde, wenn ich eine Schleifen- oder if-Anweisung bei 'Standard'-Einrückungen sehe und dann bei verschiedenen Einrückungen bemerke. Ich persönlich mag es, wenn alle meine geschweiften Klammern in der Dokumentation zusammengefasst sind, nicht nur in dem Codeblock, den ich gerade betrachte.

Insgesamt halte ich es jedoch für eine schöne Idee, aber persönlich würde ich es nicht mögen.


1

Ich habe gerade die Implementierung elastischer Tabstops in jEdit ausprobiert, die mit den mir vertrauten Programmiersprachen (hauptsächlich HTML / XML und C-ähnliche Sprachen) erstaunlich gut funktioniert. Mit Python-Code wird jedoch wie folgt gerendert (Leerzeichen anstelle von Tabulatoren, um die Ausrichtung zu veranschaulichen):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Für eine Sprache wie Python, die auf Abstand basiert, ist dies ein Deal-Breaker, es sei denn, Sie deaktivieren die von elastischen Tabstops bereitgestellten Funktionen. Editoren wie Vim und Emacs vereinfachen das Deaktivieren der meisten Arten von Funktionen, wenn Sie den Namen der Option kennen und wissen, wie sie deaktiviert werden können. Diese Funktionalität muss jedoch für Code wie den oben genannten deaktiviert werden.

Das heißt, es ist großartig für x86 ASM, C, C ++, Go, XML, HTML und andere, die nicht so sehr auf Leerzeichen setzen:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Ich werde sagen, dass Lisp-Dialekte wie Scheme ihre eigenen Konventionen haben, mit denen elastische Tabstops auch "hässlichen" Code rendern. Wenn ich meine Tabulatoreinstellungen an die Konvention von 2 Spalten anpasse und Tabulatoren an ungewöhnlichen Stellen einfüge (zwischen einer Funktion und ihren Argumenten):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

desto besser lesbar:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Zugegeben, dieses ist nicht so schlecht wie das Python-Beispiel, aber es verringert definitiv die Lesbarkeit des Codes. Während ich die Funktionalität beim Codieren in etwas wie C # oder C ++ sehr genieße, verabscheue ich die Funktionalität beim Codieren in einer Sprache wie Python oder Scheme, in der Whitespace funktionell und / oder visuell hilfreich ist. Elastische Tabstops wurden speziell erstellt, um ohne ein separates Einrückungsprogramm hilfreich zu sein, aber es ist eindeutig nicht für alle Programmiersprachen gedacht.


0

Emacs bereits behandelt Einzug in Gegenwart von nicht geschlossenen Klammern und werden automatisch ausrichten wilma mit fred . Ich habe keine Ahnung, warum Eclipse nicht dasselbe tut. Ok, ich habe eine Idee, aber sie ist unkompliziert.

Sie könnten Emacs auch dazu bringen, den Kommentar ohne viel Mühe anzupassen, aber AFAIK niemand außer Ihnen hat das jemals gewollt.


2
Ich kann Ihren letzten Satz nur als Trolling interpretieren, da es offensichtlich mindestens ein anderer Typ wollte, dass eine gut argumentierte Seite, eine Java-Implementierung und ein GIF erstellt werden, um zu zeigen, warum es gut ist. Wenn Sie die Antworten durchlesen, werden Sie feststellen, dass Nick auch nicht allein ist. Oh warte, schau auch hier .
Roman Starkov

Wird Emacs übrigens bei der wilmaBearbeitung erneut eingerückt, z. B. beim Ändern der Länge des Funktionsnamens? Wenn ja, ist das ziemlich ähnlich wie bei elastischen Tabstops.
Roman Starkov

@romkyns: Ich wollte kein Trolling sein, sondern nur, dass ich noch nie einen solchen Kommentar in EMACS gesehen habe. Im Allgemeinen werden bei der Eingabe von EMACS nicht mehrere Zeilen erneut eingerückt, dies kann jedoch auch geändert werden.
Kevin Cline
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.