Editorconfig in Visual Studio

Visual Studio bietet Entwicklern jede Menge Möglichkeiten, um die Entwicklungsumgebung an eigene Anforderungen und Wünsche anzupassen. Doch was, wenn das Team bestimmte Konventionen und Einstellung bevorzugt? Zum einen möchte man seine Einstellungen nicht mit denen aus einem Projekt “mischen”, zum anderen nicht mit den Einstellungen überspielen. Hier schafft die Editor-Config-Datei in einem Projekt Abhilfe.

Wie das in Visual Studio funktioniert und welche Einstellungen mir persönlich sehr beim Entwickeln und Refactoring in meinen Projekten geholfen haben, zeige ich in diesem Blogbeitrag.

Was ist die .editorconfig in Visual Studio?

In der Editor-Config-Datei (.editorconfig) können einheitliche Codierungsformate für das Projekt hinzugefügt werden. Der Vorteil ist, dass diese Einstellungen vor den globalen Einstellungen von Visual Studio verwendet werden und durch die Ablage im Projekt alle Entwickler im Projekt eine gemeinsame Basis haben. Die Editor-Config-Datei kann für jedes Projekt spezifisch angepasst werden. Darin werden u.a. Einstellungen für die Tab-Länge usw. vorgenommen.

Diese Einstellungen können je entsprechender Entwicklungsdatei (z.B. .cs-Dateien) im Projekt durch die Tastenkombination STRG + K, STRG + E angewandt werden. Eine Anwendung auf das ganze Projekt ist nicht möglich.

Wo sind meine Einstellungen?

Wenn man ein neues Projekt mit Visual Studio erstellt, wird zunächst keine Editor-Config-Datei für das aktuelle Projekt angelegt. Durch das Hinzufügen einer neuen Datei (via Rechtsklick) kann nach einer Editor-Datei gesucht und diese dann hinzugefügt werden. Dabei sollte der Standardname beibehalten werden.

Die Editor-Config-Datei beinhaltet eine Menge an Einstellungen, die für C#-Dateien gelten.

Die Einstellungen aus der Editor-Config-Datei gelten für alle Dateien auf derselben Ebene und der Unterordner.

Getting Started mit .editorconfig in Visual Studio

Die Editor-Config-Datei beinhaltet nun einige Einstellungen, wie z.B. die Länge eines Tabstopps oder die Verwendung von tatsächlichen Tabs anstelle von Leerzeichen:

tab_width = 4
indent_size = 4
indent_style = space

Darüber hinaus können auch Konventionen definiert werden. So kann beispielsweise festgelegt werden, dass bei der Verwendung eines IF-Statements nicht die Kurzschreibweise ohne geschweifte Klammern verwendet werden kann, sondern dass explizit welche gesetzt werden müssen - auch wenn es syntaktisch erlaubt wäre. Zusätzlich lässt sich einstellen, ob hierbei nur ein Warning oder die entsprechende Codestelle als Fehler gekennzeichnet wird.

csharp_prefer_braces = true:error

Der Name gibt die Property an, die Angabe von true oder false, ob diese angewandt werden soll und das error nach dem Doppelpunkt, wie diese Regel angewandt werden soll.

In diesem konkreten Beispiel würde hierdurch ein Fehler in der Fehlerliste erscheinen.

Dabei kann der Schweregrad (Severity) in unterschiedlichen Ausprägungen erfolgen:

• None
• Silent
• Suggestion
• Warning
• Error

Hierdurch erscheint ein Hinweis z.B. in den Warnings als Fehler oder man erhält keine Hinweise.

Meine persönlichen .editorconfig-Einstellungen

In der Vergangenheit haben mir persönlich die Editor-Config-Einstellungen insbesondere beim Refactoring geholfen. Nach dem Refactoring in einer Klasse ist beispielsweise die Sortierung der usings willkürlich oder nicht-verwendete usings verbleiben nach dem Refactoring in der C#-Datei. Bei manchen automatisch hinzugefügten usings wird selbige in vereinfachter Form hinzugefügt und nicht als fully qualified name, was u. U. zur Mehrdeutigkeit mancher usings führen kann.

Mit den folgenden Einstellungen in der Editor-Config-Datei kann dem Ganzen Abhilfe geschaffen werden:

• dotnet_sort_system_directives_first = true: Die System-usings werden alphabetisch sortiert und vor den restlichen usings eingefügt.
• dotnet_diagnostic.IDE0005.severity = error: Nicht-benötigte usings werden als Fehler erkannt und in der Fehlerliste ausgegeben.
• csharp_qualified_using_at_nested_scope = true: Das Hinzufügen von usings erfolgt als fully qualified name.

Im folgenden Screenshot sind einige usings beliebig sortiert und es befindet sich ein nicht-verwendetes usings darin:

Nach dem Hinzufügen der oben genannten Einstellungen in die Editor-Config-Datei (.editorconfig) und dem Anwenden via STRG + K, STRG + E erhält man folgende Darstellung:

Fazit zur Editor-Config-Datei in Visual Studio

Die Editor-Config-Datei gibt Teams die Möglichkeit, gemeinsam Regeln festzulegen und diese anzuwenden, auch wenn in den persönlichen Einstellungen in Visual Studio Gegenteiliges definiert wurde. Sicherlich gibt es hier noch mehr Möglichkeiten, aber ich für meinen Teil habe die größten Mehrwerte insbesondere beim Refactoring gesehen und habe mir angewöhnt, neben der Formatierung (STRG + K, STRG + D) auch die Editor-Config-Regeln (STRG + K, STRG + E) anzuwenden, bevor ich die Datei speichere und verlasse.