Editorconfig in Visual Studio in 10 Minuten oder weniger

Einführung: Warum EditorConfig wichtig ist

Tim beginnt mit der Vorstellung des EditorConfig-Projekts und erklärt, dass projektspezifische Einstellungen jetzt einfacher denn je zu implementieren sind. Anstatt sich auf persönliche Präferenzen zu verlassen, die in Visual Studio oder in den Editor-Einstellungen gespeichert sind, können Sie jetzt ein Projekt so konfigurieren, dass ein einheitlicher Codierungsstil für alle Mitwirkenden beibehalten wird.

Erstellung des Projekts

Um die EditorConfig-Datei zu demonstrieren, erstellt Tim ein neues Blazor Server-Projekt in Visual Studio. Er nennt sie BlazorDemoApp und verwendet die Standardkonfiguration. Dieses einfache .NET-Projekt dient als Testumgebung für die Einstellung und Anwendung der EditorConfig-Einstellungen.

Wie Tim erklärt, braucht dieses Projekt keine komplexe Logik oder Funktionalität. Es handelt sich lediglich um ein praktisches Beispiel für die Arbeit mit Code-Stilregeln.

Verstehen von Projektvorgaben und Codierungsstilen

Hier erläutert Tim, warum die Konfiguration auf Projektebene wichtig ist. In Visual Studio kann jeder Benutzer Voreinstellungen für Dinge wie:

• Ob Tabulatoren oder Leerzeichen verwendet werden sollen

• Die Größe des Einzugs (z. B. 3 oder 4 Leerzeichen)

• Platzierung von geschweiften Klammern {} in derselben oder in neuen Zeilen

• Die Art der Namespace-Deklaration (block-scoped oder file-scoped)

Diese Einstellungen werden in der Regel pro Benutzer in Visual Studio gespeichert, nicht pro Projekt. Tim hebt hervor, dass bei der Arbeit in einem Team die lokalen Einstellungen aller Beteiligten unterschiedlich sein können. Dies kann zu inkonsistenter Codeformatierung, unnötigen Unterschieden in Versionskontrollsystemen und Zeitverschwendung bei der manuellen Anpassung von Einstellungen führen.

Hier hilft das EditorConfig-Dateiformat - es definiert einen gemeinsamen Satz von EditorConfig-Eigenschaften, die von allen Editoren der Entwickler automatisch beachtet werden können.

Erstellen und Öffnen einer EditorConfig-Datei

Anschließend zeigt Tim, wie man eine neue EditorConfig-Datei zur Lösung hinzufügt.

Er klickt mit der rechten Maustaste auf die Lösung und wählt Hinzufügen → Neue EditorConfig. Visual Studio könnte beim ersten Laden der Datei eine kleine Fehlermeldung ausgeben, aber Tim erklärt, dass es sich dabei um eine harmlose Eigenart handelt - schließen Sie die Datei einfach und öffnen Sie sie erneut.

Diese neue Datei heißt in der Regel .editorconfig, und Visual Studio erkennt sie sofort als Konfigurationsdokument. Es ist erwähnenswert, dass Visual Studio diese Datei von Haus aus unterstützt, ebenso wie andere Texteditoren wie Visual Studio Code und sogar Sublime Text über Texteditor-Plugins.

Tim stellt klar, dass es sich bei EditorConfig nicht um ein reines Microsoft-Tool handelt. Es handelt sich um einen branchenweiten Standard, der verschiedenen Redakteuren dabei hilft, dieselben Codierungskonventionen zu verstehen und anzuwenden, um eine einheitliche Formatierung in verschiedenen Umgebungen zu gewährleisten.

Editor konfigurierenKonfigurationsdatei-Einstellungen

Sobald die EditorConfig-Datei geöffnet wird, erklärt Tim, dass sie die Standardeinstellungen aus der aktuellen Visual Studio-Konfiguration übernimmt. Diese können jedoch nach Bedarf geändert werden.

Er navigiert zum Abschnitt Whitespace und zeigt, wie man ihn einstellt:

• Tabulatoren anstelle von Leerzeichen verwenden

• Tabulatorbreite = 3

Dies sind Beispiele für EditorConfig-Eigenschaften, die festlegen, wie sich die Code-Formatierung verhalten soll. Einmal gespeichert, gilt diese Konfiguration für die gesamte Lösung, aber nicht außerhalb.

Tim merkt an, dass diese EditorConfig-Datei auch zu Versionskontrollsystemen (wie Git) hinzugefügt werden kann, um sicherzustellen, dass jeder Entwickler, der das Repository klont, dieselben Regeln erbt. Dies trägt dazu bei, eine einheitliche Formatierung beizubehalten, unabhängig davon, wer den Code schreibt.

Arbeiten mit Codestilen und Namensraumregeln

Anschließend geht Tim auf die Code-Stil-Einstellungen ein - insbesondere auf den Stil der Namespace-Deklaration.

Standardmäßig verwendet C# block-scoped Namespaces, wobei der Namespace mit geschweiften Klammern definiert wird. Tim erstellt eine Klasse unter dem Ordner Data, um dieses Format zu demonstrieren.

Anschließend ändert er die Einstellung der EditorConfig-Datei, um dateiübergreifende Namensräume zu verwenden. Wenn er eine weitere Klasse hinzufügt, wendet Visual Studio automatisch den aktualisierten Stil an und zeigt den Namensraum mit einem Semikolon (;) anstelle von geschweiften Klammern an.

Es wird gezeigt, wie die EditorConfig-Einstellungen die Standardvorlagen für die Codegenerierung in Visual Studio beeinflussen und automatisch an definierte Projektkonventionen angepasst werden können.

Tim weist auch darauf hin, dass die Codebereinigungsfunktion verwendet werden kann, um bestehende Dateien neu zu formatieren und sicherzustellen, dass der gesamte Code den neuesten EditorConfig-Regeln entspricht.

Schweregrad festlegen und Regeln erzwingen

In diesem Abschnitt konzentriert sich Tim darauf, wie die Durchsetzung von Regeln mithilfe von Schweregraden in der EditorConfig-Datei gesteuert werden kann.

Jede Regel kann einen Wert wie none, suggestion, warning oder error haben. Tim setzt den Schweregrad der Namespace-Regel auf Fehler und Visual Studio markiert sofort jede Datei, die nicht dem bevorzugten Format entspricht, im Fenster Fehlerliste.

Dies stellt sicher, dass die Entwickler den definierten Stil einhalten und verhindert unerwünschte Abweichungen in der aktuellen Datei oder im gesamten Projekt.

Auch wenn einige Ungereimtheiten oder Fehler in Visual Studio auftreten können (z. B. falsche Eingabeaufforderungen für Vorschläge), merkt Tim an, dass sich diese mit der Zeit verbessern werden. Wichtig ist, dass die Regeln konsequent angewendet werden, damit der Code leicht lesbar und einheitlich ist.

Mehrere EditorConfig-Dateien und Verzeichnisumfang

Tim erklärt weiter, dass Sie mehrere EditorConfig-Dateien in einer einzigen Lösung haben können.

Zum Beispiel:

• Eine EditorConfig-Stammdatei auf der Lösungsebene definiert allgemeine Einstellungen für alle Projekte.

• Eine verschachtelte EditorConfig-Datei in einem Unterordner wie /Data kann einige Eigenschaften außer Kraft setzen (z. B. Benennungskonventionen, Tabulatorbreite oder Zeilenumbrüche).

Jedes EditorConfig-Projekt verhält sich hierarchisch, d. h. Dateien in Unterverzeichnissen erben von den übergeordneten Verzeichnissen, sofern sie nicht explizit überschrieben werden.

Wenn Sie die Wurzel Ihrer Konfiguration definieren möchten, können Sie die Eigenschaft root = true in der Top-Level-Datei festlegen. Dadurch werden die Editoren angewiesen, nicht mehr in den übergeordneten Verzeichnissen nach weiteren EditorConfig-Dateien zu suchen.

Diese Struktur gibt den Entwicklern eine fein abgestufte Kontrolle über die Formatierungsregeln auf Projektebene, lässt aber auch Sonderfälle zu, in denen eine andere Formatierung sinnvoll sein könnte.

Abschluss: Konsistenz durch EditorConfig

In seinen abschließenden Bemerkungen ermutigt Tim die Entwickler, EditorConfig aktiv in ihren .NET-Projekten einzusetzen.

Er hebt hervor, dass dieser Ansatz es den Teams ermöglicht, konsistente Formatierungsregeln, Namenskonventionen und Layoutstile beizubehalten - und das alles, ohne Änderungen der persönlichen Editoreinstellungen zu erzwingen. Jede geöffnete Datei folgt automatisch den definierten Stilen, die in der .editorconfig-Datei des Projekts festgelegt sind.

Durch die Übertragung dieser EditorConfig-Dateien in Versionskontrollsysteme stellen die Teams sicher, dass jeder - unabhängig von seinem Editor oder seiner Umgebung - dieselben Regeln für die Codeformatierung befolgt.

Tim schließt sein Video ab, indem er betont, dass das EditorConfig-Dateiformat einfach, flexibel und weithin unterstützt ist. Unabhängig davon, ob Sie Visual Studio, Visual Studio Code oder einen anderen Texteditor verwenden, können Sie damit einen konsistenten Codierungsstil beibehalten und Ihr Projekt sauber, professionell und lesbar gestalten.