Oder: Warum ich #region nicht mag

Ich glaube jeder, der in C# .NET programmiert, kennt die #region-Direktive. In Visual Studio wird sie meistens für automatisch generierten Code (z.B. VS2003 / .NET 1.1) oder implementierte Interfaces automatisch angelegt. Da ist ja auch ansich nichts daran auszusetzen.

Aber, #region hat auch seine "böse" Seite. Es gibt einige Entwickler, die #region massiv einsetzen.

Nun, das sieht eventuell nett und aufgeräumt aus, aber das war's dann auch schon. In der Praxis ist diese penible Ordnung eher hinderlich als hilfreich. Ich z.B. finde es schon wichtig, den ganzen Code einer Klasse überblicken zu können. Da lernt man schnell den Shortcut zum aufklappen aller #region's (CTRL+M & CTRL+L). Abgesehen davon liefert #region eigentlich keinen praktikablen Mehrwert (bis auf einige seltene Ausnahme-Situationen).

Besonders störend sind Regions, wenn die Quell-Dateien unter Versions-Kontrolle stehen, z.B. SVN oder TFS. Da kann ein Merge oder eine Conflict-Behebung zur Tortur werden. Meistens ist auf den ersten Blick nicht immer ersichtlich, wo die eine #region anfängt und aufhört. Konsequenterweise schlägt dann auch ab und an mal der automatische Build fehl, weil der Compiler über eine fehlende #region- oder #endregion-Direktive meckert. Da kann man sich schon mal darüber aufregen.

Ein weiterer Nebeneffekt der exzessiven Verwendeung von Regions ist sicherlich, das man mit der Zeit dazu neigt, sich das Leben einfach zu machen und eine Klasse unnötig zu vergrößern oder sich Refaktorisierungs-Arbeit zu ersparen.

Die #region-Direktive hat sicherlich seine Daseinsberechtigung - sollte aber wirklich nur dann eingesetzt werden, wenn es wirklich einen Mehrwert bringt. Zum strukturieren, ordnen oder leichteren Finden von Code macht es sicherlich in den meisten Fällen keinen Sinn. Das sehen einige andere Entwickler genauso, insofern kann man wohl von einer Best-Practice sprechen, #regions mit Bedacht selten einzusetzen.


(c) Copyright . 1998 - 2013. Ilker Cetinkaya.