EditorConfig und mitversionierte Editor-Einstellungen: die kleinen Konventionen, die Whitespace-Diffs verhindern

Worum es geht

EditorConfig ist ein Dateiformat zusammen mit einer Reihe von Editor-Plugins. Eine .editorconfig-Datei verwendet INI-Syntax mit Glob-Abschnitten ([*], [*.py], [Makefile]) und einer kleinen Menge von Eigenschaften: indent_style, indent_size, tab_width, end_of_line, charset, trim_trailing_whitespace und insert_final_newline. Die Projektseite beschreibt die Suche: Plugins suchen nach .editorconfig im Verzeichnis der geöffneten Datei und in jedem übergeordneten Verzeichnis, die Suche endet, wenn die Dateisystemwurzel erreicht oder eine Datei mit root = true gefunden wird, und Eigenschaften aus näher gelegenen Dateien haben Vorrang. Editorspezifische Workspace-Einstellungen ergänzen das. VS Code etwa speichert Workspace-Einstellungen im Ordner .vscode und hält fest, dass die Einstellungen für das Projekt von allen Nutzern dieses Projekts gemeinsam verwendet werden, sobald die Datei der Versionskontrolle hinzugefügt wird; eine extensions.json im selben Ordner listet empfohlene Erweiterungen auf.

Warum es wichtig ist

Gemischte Tabs und Leerzeichen, CRLF-Zeilenenden und fehlende abschliessende Leerzeilen erzeugen Diffs, die die eigentliche Änderung verdecken, und lösen Formatter-Konflikte zwischen Mitwirkenden und Agenten aus, die unterschiedliche Editoren verwenden. Plugins lesen die Datei beim Öffnen einer Datei und wenden die Einstellungen beim Tippen und Speichern an, noch bevor ein Formatter oder Hook läuft; die Projektseite listet Editoren auf, die das Format nativ ohne Plugin unterstützen.

So wird es angewendet

• Eine .editorconfig mit root = true im Wurzelverzeichnis des Repositorys versionieren, dazu einen [*]-Abschnitt (end_of_line = lf, charset = utf-8, insert_final_newline = true, trim_trailing_whitespace = true) und Abschnitte für die Einrückung je Sprache; Makefiles brauchen indent_style = tab.
• Sie mit der Konfiguration des Formatters abstimmen, damit Editor und Formatter nie widersprechen; der Formatter bleibt die massgebliche Instanz, EditorConfig ist die erste Verteidigungslinie.
• Workspace-Einstellungen nur dort versionieren, wo sie Projektentscheidungen abbilden (Format on Save, der gewählte Formatter, Pfade des Testrunners), und Themes, Tastenkürzel und Schriftarten aussen vor lassen. Eine Datei mit empfohlenen Erweiterungen ist ein Hinweis, keine Pflicht.
• end_of_line mit text=auto in .gitattributes kombinieren (siehe den verwandten Artikel), damit ein Checkout unter Windows kein CRLF wieder einführt.
• Beide Dateien im Einführungsweg für neue Mitwirkende erwähnen, damit klar ist, dass sie beabsichtigt sind.

Stolpersteine

Die Projektseite weist darauf hin, dass nicht jede Eigenschaft von jedem Plugin unterstützt wird; Eigenschaften ausserhalb der Kernmenge sind am wenigsten portabel. trim_trailing_whitespace beschädigt Markdown, das zwei abschliessende Leerzeichen für Zeilenumbrüche verwendet; dafür einen [*.md]-Abschnitt ergänzen, der die Eigenschaft deaktiviert. Eine mitversionierte Einstellungsdatei mit den absoluten Pfaden einer Person bricht bei allen anderen. EditorConfig formatiert bestehende Dateien nicht neu; den Formatter einmal laufen lassen und das separat committen.