Definitelytyped: Tabulatoren statt Leerzeichen?

Es gibt keinen Kampf. Verwenden Sie Registerkarten.

Ich stimme für Räume!

Lassen Sie den internen Konflikt beginnen! :Lächeln:

Haha. das brauchen wir nicht. Aber weißt du... wir würden diese Unterhaltung nicht führen, wenn wir Tabs verwenden würden und jeder Entwickler seinen Code immer noch perfekt so ausgerichtet hätte, wie er es wollte (2 Leerzeichen oder 4 Leerzeichen). Nur sagen.

Ich mag Tabs.
aber ich denke, dass wir uns an die Standardeinstellungen für VisualStudio halten sollten.

Leerzeichen mit einer Einzugsgröße von 4 (VS-Standardeinstellungen).
Stellen Sie Ihre IDE so ein, dass virtuelle Registerkarten für Sie und alle glücklich sind.
Ich mag es einfach nicht, [Tab] [Tab] [Leerzeichen] [Leerzeichen] [Leerzeichen] für Code zu sehen, der sich an einem Wort in der oberen Zeile ausrichten möchte.

Wenn jemand Lust hat, eine TSLint-Regel zu schreiben, um einen konsistenten Stil zu erzwingen (zB: entweder Tabs oder 4 Leerzeichen, aber nicht beides), dann würden wir sie in einem neuen Tester ausführen (er hat TSLint-Unterstützung).

Siehe auch https://github.com/palantir/tslint/issues/122

Räume! FWIW JS-Bibliotheken verwenden Leerzeichen (angular / jquery)

Dies ist wahrscheinlich auf Crockford zurückzuführen: http://javascript.crockford.com/code.html

Die Einrückungseinheit ist vier Leerzeichen. Die Verwendung von Tabstopps sollte vermieden werden, da es (zu diesem Zeitpunkt im 21. Jahrhundert) noch keinen Standard für die Platzierung von Tabstopps gibt. Die Verwendung von Leerzeichen kann zu einer größeren Dateigröße führen, aber die Größe ist über lokale Netzwerke nicht signifikant, und der Unterschied wird durch Verkleinerung beseitigt.

Da TS JS ist, sollten wir uns wirklich anpassen.

Nun, Crockford ist ein ziemlich mürrischer alter Kerl, also nehme ich ihn mit Vorsicht.

Es gab vor einiger Zeit eine Statistik auf Reddit, in der jemand einen anständigen Teil von Github analysiert hat und es waren 60% / 40% zugunsten von Leerzeichen. Ich selbst und alle Orte, an denen ich bisher gearbeitet habe, waren Tabs (obwohl ein großer Teil davon AS3 war). Es funktioniert total gut. Code-Anpassung ist Zeitverschwendung, aber bei Bedarf funktionieren Smart-Tabs auch dort gut.

Der wahre Fluch, den ich loswerden möchte, sind gemischte _Einrückungen_. Bevor wir auf das eine oder andere über das gesamte Repo thermonuklear gehen, muss es zumindest _pro Datei_ konsistent sein.

Irgendwann werden wir #2228 machen, aber das ist ein ziemlich großer Schritt (verdreht viele Zuschreibungen, damit wir @dt-bot machen können).

Nun, Crockford ist ein ziemlich mürrischer alter Kerl, also nehme ich ihn mit Vorsicht.

einverstanden

Wenn Sie sich jemals langweilen, empfehle ich, die Pull-Requests an JSON.js zu lesen. ausnahmslos werden sie von Leuten eingereicht, die Dougs leicht abgedroschene Art nicht kennen. Sie werden alle direkt abgelehnt :-)

Habe gerade das gesehen: https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199 -L213 die Standardeinstellungen sind 4 Leerzeichen mit in Leerzeichen umgewandelten Tabs

    export class EditorOptions {
        public IndentSize: number = 4;
        public TabSize: number = 4;
        public NewLineCharacter: string = "\r\n";
        public ConvertTabsToSpaces: boolean = true;

        public static clone(objectToClone: EditorOptions): EditorOptions {
            var editorOptions = new EditorOptions();
            editorOptions.IndentSize = objectToClone.IndentSize;
            editorOptions.TabSize = objectToClone.TabSize;
            editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
            editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
            return editorOptions;
        }
    }

Wie befriedigend @basarat!

Die CRLFs sind ein bisschen dumm, aber was solls.

Vielleicht sollten wir es einfach angehen. Ich werde versuchen, typescript-formatter für alles auszuführen und zu sehen, was passiert.

Sehr geehrter Herr, was für ein Schlachthof.. 562 .d.ts-Dateien insgesamt, davon 446 Dateien geändert..

https://github.com/Bartvds/DefinitelyTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3

https://github.com/Bartvds/DefinitelyTyped/commit/34907936bfc22562f30bb09ee82282ca0515b8b3

Leider konnten wir nicht das gesamte Diff anzeigen, da sich zu viele Dateien (446) geändert haben

He.

Und habe auch die Tests gemacht:

https://github.com/Bartvds/DefinitelyTyped/tree/46f9d17b2b074c887bff35b06112070b28924248

https://github.com/Bartvds/DefinitelyTyped/commit/46f9d17b2b074c887bff35b06112070b28924248

Leider konnten wir nicht das gesamte Diff anzeigen, da sich zu viele Dateien (442) geändert haben.

Schön. Wir haben also die Technologie, das war der einfache Teil. Aber jetzt müssen wir entscheiden, ob dies etwas ist, was wir wollen, weil es ernsthafte Auswirkungen haben wird.

Für eine Zeile wird die Attribution zur Hölle. Und wenn wir das akzeptieren, sollten wir wahrscheinlich die Formatierung im Tester erzwingen. Ich habe das TSLint-Setup im Tester (aber es ist deaktiviert), damit kann viel passieren.

Vielleicht sollten wir den Tester zu einem CLI-Hilfsprogramm verbessern, das den Formatierer ausführen und die Tests auf eine gut nutzbare Weise ausführen kann (es funktioniert jetzt lokal, sollte aber mit einer sauberen CLI-API usw. verbessert werden).

Ich sage je früher desto besser. Aber die gute Nachricht ist, dass Sie die Schuldgeschichte nicht verlieren werden . Ich wünschte, GitHub hätte diese Funktion auch in ihrer Diff-Ansicht implementiert.

Ja, aber es ist scheiße, dass git blame -w -M online nicht funktioniert. Ich habe gerade eine E-Mail an den Github-Support gesendet.

@Bartvds , irgendeine Antwort von GitHub?!

Das Ignorieren von Leerzeichen in der Schuldansicht von GitHub ist derzeit nicht möglich, aber wir könnten es in Zukunft hinzufügen. Vielen Dank für den Vorschlag. Ich füge ihn der Feature Request List hinzu, damit das Team ihn sehen kann.

Kann also, wenn überhaupt, eine Weile dauern.

Es ist mir egal, was die vermeintlichen Besserwisser oder Styleguides sagen – Tabs zum Einrücken sind die einzige Möglichkeit, die Absicht des Entwicklers beizubehalten, wenn es um die Ausrichtung geht. Siehe dazu meinen Blogbeitrag .

Das Konzept der Codeausrichtung (in Ihrem Fall auf var und = ausrichten) ist gut. Aber bei Refactorings schwer zu pflegen. Also benutze ich es einfach nicht. Auch automatische Formatierungstools respektieren dies nicht, z. B. Autoformatierungscode in TypeScript

Auch für

  public string FirstName { get; set; }        =>  public  string  FirstName { get; set; }    
  public string Surname { get; set; }          =>  public  string  Surname   { get; set; }
  public int Age { get; private set; }         =>  public  int     Age       { get; private set; }
  private Address Address { get;  set; }       =>  private Address Address   { get; set; } 

Fügen Sie eine neue Eigenschaft hinzu und Sie müssen alle diese Zeilen _reformatieren_. Keine gute Codeänderung zum Überprüfen.

Ihr Arbeitsablauf kann anders sein und dies möglicherweise zulassen. Es macht es viel einfacher zu lesen (Code als Kunst), aber ich habe es nicht geschafft, Teams zu erleben, die sich darauf bewegen.

Es ist das Seltsamste. Meine instinktive Reaktion auf die Idee, Tabs und Leerzeichen zu mischen, ist, zu zittern und zu denken: "Das ist einfach dreckig!"

Völlig irrational ich weiß - aber ganz aufrichtig. Menschen sind komisch...

@johnnyreilly du bist Opfer eines weit verbreiteten Missverständnisses . Die Verwendung von Tabulatoren zum Einrücken und Leerzeichen zum Ausrichten ist NICHT dasselbe wie das _mischen_ von Tabulatoren mit Leerzeichen. Du hast den Blogpost offensichtlich nicht gelesen.

Die Verwendung von Tabs für die Ausrichtung ist der Grund, warum so viele Tabs überhaupt deaktiviert wurden, weil die Leute es falsch gemacht haben. Hätten sie es von Anfang an richtig gemacht, hätte niemand bemerkt, dass sie die Präferenz ihres Editors geändert haben, die Tabulatorbreite in einer anderen Größe anzuzeigen. Dies ist, was das animierte Gif oben versucht zu demonstrieren, wie die Leute es falsch gemacht haben.

@basarat , da stimme ich dir

Natürlich gibt es noch viele andere Gründe, in der heutigen Zeit keine Leerzeichen zum Einrücken zu verwenden. Redakteure kommen gut mit Tabs zurecht, aber nie mit Leerzeichen. Pfeiltastennavigation, Löschen, Rücktaste – sie behandeln einen Leerzeicheneinzug nicht wie eine Einheit. Ich habe Visual Studio, Sublime, PHPStorm und Notepad++ verwendet, aber alle haben dieses grundlegende Problem mit Leerzeichen für Einrückungen.

Pfeiltastennavigation, Löschen, Rücktaste – sie behandeln einen Leerzeicheneinzug nicht wie eine Einheit.

Navigation: Ich benutze Strg + Pfeiltasten. Sie springen Leerzeichen (alles Leerzeichen wirklich) + Wörter.

Zum Löschen / Rücktaste: Für die Wortauswahl verwende ich Wort erweitern (Strg+W von den Resharper-Standards) und Auswahl aufheben (Strg+Umschalt+W). Ich muss jedoch selten _inside_ Whitespace auswählen, verwende einfach Tab (Einzug erhöhen) und Tabulator verschieben (Einzug verringern).

@jedmao eigentlich habe ich deinen Standpunkt verstanden - ich habe nur meine instinktive (und irrationale) Reaktion geteilt. Ich habe nicht gesagt, dass es Sinn macht :smile:

@johnnyreilly kriegt hin .

@basarat Ich verwende die Home und End in einigen Ihrer Whitespace-Szenarien. Ich habe versucht, die Ctrl + arrow key Navigation zu verwenden, aber es funktioniert nicht immer. Deshalb benutze ich es selten aus mentaler Konsequenz. Betrachten Sie das folgende Beispiel:

for (var i = 0; i < 10; i++) {
    if (i > 5) {
        console.log('I am greater than 5');
    }
}

Angenommen, mein Cursor steht am Anfang von Zeile 3 und ich möchte bis zum Anfang von Zeile 2 navigieren.

Mit deiner Technik in Sublime könnte ich es auf zwei Arten tun:

• Up , Hold Ctrl , Left , Release Ctrl (4 logische Schritte)
• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Left , Release Ctrl (8 logische Schritte)

In Visual Studio kann das 2. Szenario auf 7 logische Schritte reduziert werden.

• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Release Ctrl (7 logische Schritte)

Bei tatsächlichen Tabulatorzeichen beträgt der kürzeste Pfad nur 2 logische Schritte ohne Zusatztasten. Könnte nicht einfacher sein.

• Left , Up

Ich kann nicht erkennen, wie die Wortauswahl beim Löschen oder Zurücksetzen eines Leereinzugs helfen würde. Ich versuche es in Visual Studio ohne Erfolg. Aus diesem Grund habe ich das TabSanity Plugin für Visual Studio erstellt . Leider sind mir solche Plugins für andere Editoren nicht bekannt.

Bei tatsächlichen Tabulatorzeichen sind es immer 2 logische Schritte ohne Zusatztasten. Könnte nicht einfacher sein

:+1: Ich sehe deinen Vorteil. Wenn ich jedoch diesen Kommentar bearbeite, funktioniert Strg usw. genauso wie mein VS, also übertragen sich meine Gewohnheiten;)

Ich sehe nicht, wie die Wortauswahl beim Löschen oder Zurücksetzen eines Leereinzugs helfen würde

Meine schlechte, meine Beschreibung war verwirrend. Ignorieren Sie das Auswahlbit "Wort". Konzentrieren Sie sich einfach auf I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). Es funktioniert gut mit Einzügen mit Abstand.

Bei tatsächlichen Tabulatorzeichen sind es immer 2 logische Schritte ohne Zusatztasten.

Wie wäre es mit :

public  string  FirstName { get; set; }    
public  string  Surname   { get; set; }
public  int     Age       { get; private set; }
private Address Address   { get; set; } 

Wäre nicht vom Anfang von Age zu einer Änderung des Typs von Surname übergegangen, dh das string in der vorherigen Zeile wäre dasselbe wie das Ctrl Szenario?

@basarat Ich benutze Tab und Shift+Tab religiös; jedoch normalerweise für mehrere Codezeilen. Ich denke, man könnte sagen, dass Shift+Tab ein guter Alias ​​für einen backspace Tastendruck auf einer Registerkarte ist, aber es ist eindeutig nicht so einfach oder intuitiv wie ein backspace .

Ctrl+Delete wäre der Aliasname, der dem Schlüssel Delete am nächsten kommt, aber er hat das Potenzial, mehr als einen Einzug zu löschen; wohingegen eine einfache Delete Taste auf einer Registerkarte nur einen Einzug entfernt. Manchmal zu arbeiten und andere nicht, ist der Grund, warum ich es überhaupt nicht verwende (mentale Konsistenz).

Ich, wie Sie, muss auch selten, wenn überhaupt, innerhalb von Leerzeichen auswählen. Ich habe nie vorgeschlagen, dass ich es tun würde. Ich wähle nicht den Leerraum aus, sondern navigiere durch ihn, um irgendwohin zu gelangen. In Ihrem obigen Ausrichtungsbeispiel würde ich definitiv die Ctrl + arrow key Navigation verwenden. Aus diesem Grund verwende ich, wie bereits erwähnt, selten die Ctrl + arrow key Navigation, da das von Ihnen beschriebene Szenario wahrscheinlich der einzige Fall ist, in dem ich sie verwenden würde.

Am Ende des Tages stört mich am meisten, dass Sie Ihr Muskelgedächtnis völlig ändern müssen, wenn Sie zwischen einer Datei mit Tabulatoren zum Einrücken und Leerzeichen zum Einrücken wechseln. Was in einer Datei mit Tabulatoren zum Einrücken effizient ist (wenigste logische Schritte), funktioniert in einer Datei mit Leerzeichen zum Einrücken einfach nicht. Sie könnten den Editoren die Schuld geben, dass sie Ihnen keine nahtlose Erfahrung bieten, aber das ist nicht fair, da es für Editoren (ohne CST) buchstäblich unmöglich ist, in einer Datei mit Leerzeichen für Einrückungen Annahmen darüber zu treffen, was ein Einzug und was eine Ausrichtung ist.

Was noch frustrierender ist, ist, dass es für die Leute so schwer ist, es zu erkennen. Leerzeichen zum Einrücken sind pures Übel... mit Hörnern.

Schlußfolgerung? Ich möchte nur dazu beitragen, was zum Teufel benutzt du?

Schlußfolgerung? Ich möchte nur dazu beitragen, was zum Teufel benutzt du?

Konsistent pro Datei. Mischen Sie diese nicht in einer Datei

@basarat der Comic ist falsch. Wir alle wissen, dass der Apple-Typ Leerzeichen und der Microsoft-Typ Tabs verwenden würde.

@jedmao Ich bin ein

Ich denke, #4211 ist ein schöner Vorschlag.

Ich würde vorschlagen, 2 Leerzeichen wie im Airbnb/Javascript- Styleguide zu verwenden ...

Vorschlag: Verwenden Sie die Codierungsstandards der zu typisierenden Bibliothek. Wenn die zu typisierende Bibliothek Leerzeichen, einfache Anführungszeichen und LFs verwendet, gehen Sie in der Typdefinition genauso vor. Auf diese Weise können wir das Argument Leerzeichen vs. Tabulatoren vermeiden.

Das einzige Problem ist, dass es nicht einfach sein wird, diese Regel durchzusetzen. Wenn Sie es erzwingen und volle Konsistenz haben müssen, würde ich empfehlen, die gängigsten Konventionen zu verwenden. Laut dieser Website sind es Leerzeichen und einfache Anführungszeichen.

Meine persönliche Vorliebe sind Leerzeichen (4) und _doppelte_ Anführungszeichen, aber ich bin damit einverstanden, einfache Anführungszeichen zu verwenden, wenn dies bedeutet, dass alles konsistent ist.

Könnten die Pro-Tab- und Pro-Tab-Space-Benutzer einen ähnlichen Kompromiss akzeptieren?

Meine persönliche Vorliebe sind Leerzeichen (4) und doppelte Anführungszeichen, aber ich bin damit einverstanden, einfache Anführungszeichen zu verwenden, wenn dies bedeutet, dass alles konsistent ist.

@glen-84 nur zu Ihrem Vergnügen ... hier warum das Compiler-Team doppelte Anführungszeichen verwendet hat: https://github.com/Microsoft/TypeScript/issues/5811#issuecomment -160187924

• JSON
• Funktioniert in allen Sprachen, daher weniger kognitive Belastung

Ich persönlich gehe selbst mit einfachen Anführungszeichen, da ich immer mehr ausschließlich TypeScript mache :rose:

Ich denke, es ist auch etwas besser lesbar, und es waren 57% gegenüber 43% (kein großer Unterschied), aber ich denke, irgendwo muss man die Grenze ziehen. =)

Ich mag den Punkt von @jedmao auf Registerkarten für Einrückungen und Leerzeichen für die Ausrichtung.

Vollständige Offenlegung: Ich komme aus dem Go-Land, wo wir go fmt und keine Diskussionen über Tabs oder Leerzeichen haben. Es sind Tabs zum Einrücken und Leerzeichen zum Ausrichten und es funktioniert sehr, sehr gut :+1:

Räume natürlich. Denn niemand weiß, wie die Tabs in verschiedenen Editoren genau gerendert werden, wenn sie woanders verwendet werden.

@hinell warum ist es wichtig, wenn Tabs in verschiedenen Editoren unterschiedlich gerendert werden? Sollte es nicht, solange Tabulatoren "nur" zum Einrücken verwendet werden.

Ich bevorzuge Tabs, vor allem deshalb: http://nickgravgaard.com/elastic-tabstops/

Es stellt sich heraus, dass es noch einen größeren Grund gibt, Tabs zu verwenden: die Zugänglichkeit für Entwickler .

• https://github.com/prettier/prettier/issues/7475
• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/