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!)