Regions or no regions – this is the question

Die dnc12 ist gerade vorbei und wir könnten uns schon wieder zusammensetzen 🙂
Heute gab es auf Twitter eine kurz angerissene Diskussion, die das Zeug dazu hatte, die Gemüter aufzuheizen: soll man oder soll man nicht #regions nutzen?

 

Nach dem kurzen Tweet-Austausch wurde es klar, dass es viele Entwickler gibt, die Regions gerne nutzen. Ich habe zwar den ganzen Abend nachgedacht, habe allerdings keine Gründe gefunden, sie selbst verwenden zu wollen.

 

Ich meine, warum sollte man Code NICHT sehen wollen?

  • Geht es vielleicht um eine oder mehrere Methoden, die man ausblenden will? Das würde aber entweder bedeuten, dass man
    – die Funktionalität der ganzen Klasse ausblendet, aber dann wozu, man öffnet einfach die Klasse nicht 😉
    – nur ein Teil der Funktionen ausblendet, und dann stellt sich die Frage, warum manche Funktionen viel öfter angeschaut werden als andere? Das hat für mich irgendwie ein CodeSmell
  • Geht es vielleicht um ein Teil einer einzigen Methode, und zwar einer ganz großen, sonst würde man sie nicht teilweise ausblenden wollen? Zusammengeklappt würde man dann eine Art Kommentar sehen, was mich sofort an Martin Fowlers Hinweis bezüglich Kommentare erinnert hat: Kommentare sind ideale Namensgeber. Wenn man im Code einen Kommentar braucht, dann ist das meistens ein Smell für ein Extract Method (genauso wie die Tatsache, dass die Methode wahrscheinlich zu lang ist)

    You have a code fragment that can be grouped together.

    Turn the fragment into a method whose name explains the purpose of the method.

  • Geht es vielleicht um Regionen um Methoden, Events, Fields, Properties, also nach Sichtbarkeit und Rolle? Dafür könnte ich einen einzigen Grund vorstellen, und zwar den, dass man auf Anhieb die öffentliche Methoden und Eigenschaften sehen will. Das wäre allerdings die Aufgabe eines Interfaces, oder? Dazu kommt auch noch meine – persönliche – Vorliebe, Code wie ein Buch zu lesen, von oben nach unten, also von einer öffentlichen Methode weiter in die Details, also zu den privaten Methoden (ganz nach CCD – Single Level of Abstraction (SLA))

    Hilfreich als Analogie ist der Blick auf Artikel in der Tageszeitung: dort steht zu oberst das Allerwichtigste, die Überschrift. Aus ihr sollte in groben Zügen hervorgehen, wovon der Artikel handelt. Im ersten Satz des Artikels wird dies auf einem hohen Abstraktionsniveau beschrieben. Je weiter man im Artikel fortschreitet, desto mehr Details tauchen auf. So können wir auch unseren Code strukturieren. Der Name der Klasse ist die Überschrift. Dann folgen die öffentlichen Methoden auf hohem Abstraktionsniveau. Diese rufen möglicherweise Methoden auf niedrigerem Niveau auf, bis zuletzt die “Bitpfriemelmethoden” übrig bleiben. Durch diese Einteilung kann ich als Leser der Klasse entscheiden, welchen Detaillierungsgrad ich mir ansehen möchte. Interessiert mich nur grob, wie die Klasse arbeitet, brauche ich mir nur die öffentlichen Methoden anzuschauen. In ihnen wird die Funktionalität auf einem hohen Abstraktionsniveau gelöst. Interessieren mich weitere Details, kann ich tiefer einsteigen und mir die privaten Methoden ansehen.

Was meint ihr, übersehe ich da was? (Notiz an mich: bei #nossued das Gespräch fortsetzen!)

  • Ich hatte vor einer ganzen Zeit lang auch meine Ablehnung gebloggt: http://code-inside.de/blog/2010/09/08/region-failcode/ In den Kommentaren gab es ein paar Anregungen zu dem Thema.

  • Wir sind hier auch mehr oder weniger gezwungen #regions zu verwenden.
    Warum? Clean Code ist hier ein Thema das noch ganz am Anfang steht, und die Klassen meist viel zu groß,lang oder was auch immer sind. Und es gibt eine Vorgabe von weit oben. 🙁
    Zuerst hatte ich mich auch gefreut eine, auf dem ersten Blick, übersichtliche Klasse zu haben. Aber die Suche nach Blöcken macht es auch nicht einfacher.
    Was würde helfen? Refactoring, aber auch das ist ein Thema das hier weit nach hinten geschoben wird… “haben wir Angst davor, keine Zeit, usw.”
    Mein Fazit zu dem Thema, vorübergehend sind #regions ok, aber so bald “aufgeräumt” wird, werden die so schnell entfernt wie sie erstellt worden sind.

  • Florian Witteler

    Ich spreche mich auch ausdrücklich gegen #regions aus. Aus meiner Sicht verringern sie die Übersicht, also genau konträr zu ihrer eigentlichen Aufgabe.

  • Ich finde Regions ok, stören mich nicht, einsetzen tue ich diese, wenn dann nur um private Member und private Methoden in “Bereiche” zu schieben. Mit Strg M + O lassen sich die Regions einklappen und mit Strg M + L einfach wieder ausklappen. Also das ich irgendwas nicht sehen kann, weil in einer Region “versteckt”, zählt nicht : )

  • Sebastian

    Für mich sind regions ein gutes Ordnungsmittel das ich sehr mag, es hängt aber immer davon ab was ich mache.

    regions können guten code besser machen und schlechten code noch schlechter. sie machen schlecht organisierten/strukturierten code aber in keinem fall besser.(hat glaube ich auch nie jemand behauptet)