Jak zwykle układasz regiony klasy?

Zastanawiałem się, czy istnieje standard wyznaczania regionów klasy.

Obecnie używam

Fields
Constructor
Properties
Public Methods
Private Methods

Fieldsbędąc własnością prywatną i Propertiesbędąc własnością publiczną. Zwykle użyję podregionów, jeśli to konieczne, lub od czasu do czasu dodam inne regiony poniżej (takie jak interfejs lub członkowie baseClass).

Wyliczenia związane z klasami lub czasami struktury / klasy czystych danych (powyżej rzeczywistej definicji klasy)

--- Definicja klasy ---

Członkowie prywatni

CTOR / DTOR, jeśli język ma DTOR

Nieruchomości publiczne

Metody użytkowe (prywatne lub chronione metody o małym zakresie)

Funkcjonalność klasy (może być podzielona na wiele regionów w zależności od zakresu klasy).

Podregiony? Czy Twoja klasa ma jedną odpowiedzialność ? (domyślnie w tym ... moja odpowiedź brzmi: „Rzadko jakikolwiek region, może z wyjątkiem grupowania właściwości, konstruktorów i metod” ... ale nawet wtedy nie używam go zbyt często)

Chciałem tylko potwierdzić, że masz na myśli „#regiony”, a nie ogólny układ zajęć.

Dziwi mnie, że nikt nie wspomniał o tym, by unikać korzystania z regionów. Rozumiem, że PO chce przeprowadzić ankietę na temat wyznaczania regionów, ale chciałbym podnieść alternatywny punkt widzenia.

Unikam regionów. Lubię widzieć kod, z którym pracuję. Jeśli trudno ci znaleźć to, czego szukasz, użyj zwijania kodu i grupuj podobne konstrukcje klas razem.

Dlaczego nienawidzę regionów? CTRL+M,Li CTRL+M,Oprzełącza składanie kodu. Jednak po zwinięciu ukrywa cały region. Muszę tylko zwinąć metody / właściwości / komentarze.

Jeśli jest zbyt wiele regionów, być może pachnie kodem, a twoja klasa wykonuje zbyt wiele pracy. Jeff Atwood zapewnia dobry post na temat regionów, które warto przeczytać.

Mój ulubiony cytat na #regionach:

Nie, nie będę używać #regionów. I nie, NIE NEGOCJUJĘ Z TERRORYSTAMI. Zamknij się.

- Jeff Atwood

Biorąc to pod uwagę, wiem, że wielu programistów upiera się przy ich użyciu. To pytanie jest subiektywne. Pomyślałem, że zaoferuję alternatywę.

Różni się w zależności od języka. Ponieważ jestem koderem Delphi, mam tendencję do przestrzegania standardowej konwencji Delphi, która wygląda następująco:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

Uważam, że to dobry sposób na uporządkowanie informacji, które są łatwe do odczytania i zrozumienia.

Zazwyczaj układam je w następujący sposób:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

Nie używałem języka, który używa Properties, dlatego nie są one określone. Umieszczam prywatne metody i pola na dole, ponieważ jeśli ktoś inny używa tego pliku w swoim kodzie, powinien tylko zająć się interfejsem API, który jest sprawą publiczną. Wszystkie znane mi edytory tekstu, a nawet IDE, ustawiają kursor na górze podczas otwierania plików.

To dla mnie wezwanie do osądu. Korzystam z regionów, gdy są one potrzebne dla czytelności.

Używam także innego koloru w moim schemacie kolorów Visual Studio (obecnie ciemnoczerwonym), aby wyróżniały się na tle pozostałej części kodu.

Przykład zastosowania #regionu: jeśli napiszę metodę testową dla testu jednostkowego wymagającą wielowierszowego fragmentu kodu XML, łańcuch XML przerwie zwykłe wcięcie (ponieważ zaczyna się wzdłuż lewego marginesu okno kodu. Aby ukryć brzydotę, zawinę ją w region #, aby móc go zwinąć.

Książka Czystego Kodu Boba Martina poświęca cały 5 rozdział formatowaniu. Jest kilka kluczowych kwestii, które według mnie ładnie podsumowują.

• Większość prób grupowania zmiennych i metod według widoczności i czystości Nie ma większego sensu i powoduje, że często poruszasz się po kodzie.
• Utrzymywanie metod, które nazywają się nawzajem pionowo, zmniejsza ilość nawigacji, którą musisz wykonać, i ułatwia znajdowanie rzeczy.
• Twój ciąg myśli nie zostanie przerwany, jeśli będziesz musiał się zatrzymać i pomyśleć „w jakim regionie należy ten fragment kodu?” co kilka minut.
• Zmienne instancji powinny zwykle być nieliczne i powinny być używane wszędzie, dlatego należą one do czołówki klasy, w której najłatwiej je zlokalizować. Zmienne i deklaracje, które będą używane tylko przez jedną metodę, muszą istnieć wewnątrz tej metody. Jeśli są używane tylko przez kilka metod, powinny być blisko w pionie, ale powyżej kilku metod, które ich używają.

Utrzymywanie kodu uporządkowanego z często oddziałującymi elementami w pionie blisko siebie skutecznie eliminuje potrzebę tworzenia określonych regionów. Jeśli twój kod jest tak długi, że wymaga od regionów, aby ukrył dużo kodu, być może jest to zapach kodu wskazujący, że klasa próbuje zrobić zbyt wiele. Być może niektóre funkcje można przenieść do klasy użytkowej lub przekazać przodkowi.

Jeśli musisz „ukryć” kod, ponieważ jest on zbyt długi lub „brzydki”, prawdopodobnie masz większe problemy do zmartwienia niż to, czy chcesz użyć regionów. Osobiście nigdy nie muszę ich używać, a kiedy pracuję nad czyimś kodem, stwierdzam, że i tak zawsze muszę je wszystkie otwierać, więc po co się tym przejmować?

Obecnie układam takie klasy:

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

a następnie prefiks poziomu dostępu do każdej deklaracji (rodzaj, czasem grupowanie według dostępu). Kiedyś grupowałem na najwyższym poziomie według dostępu, ale w pewnym momencie nie wiem, kiedy to nie działało tak dobrze jak wyżej. Na przykład w C ++ / CLI (z którego jestem obecnie zmuszony korzystać :-() możesz to zrobić, co zakłóca grupowanie według dostępu:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

Szaleńcza odpowiedź: Nie, przynajmniej jeśli chodzi o C #. Pomiędzy Visual Studio i R # Mogę magicznie nawigować do dowolnego członka lub implementacji, więc nie ma sensu mieć obsesji na punkcie tych rzeczy; po prostu zacznij pisać w miejscu, w którym znajduje się kursor.

Podobnie jak Wyatt i kilka innych odpowiedzi, generalnie również unikam używania regionów. Regiony mają jeden cel; aby ukryć kod, na który nie chcesz patrzeć. Jeśli masz dużo kodu w klasie, na którą nie chcesz patrzeć, a zatem potrzebujesz wielu regionów, aby umożliwić zwinięcie wspomnianego kodu, prawdopodobnie masz za dużo kodu w klasie. ReSharper nie szanuje regionów przy podejmowaniu decyzji, gdzie umieścić nowy kod, chyba że utworzył region (co robi dla implementacji interfejsu).

Jedynym zastosowaniem regionów, które uważam za dopuszczalne, jest ukrycie „nieuchronnie brzydkiego” kodu; kod zajmujący się szczegółowymi szczegółami implementacji, które nie mogą być dobrze zaprojektowane wewnętrznie zgodnie z obecnymi standardami. Zwykle jest to zaawansowany, ezoteryczny kod, który zwykle nie powinien być pomylony przez przeciętnego młodszego programistę po napisaniu. Są to takie rzeczy jak:

• Niektóre wbudowane implementacje interfejsu (IDisposable, IConvertible, czasem IEnumerable lub IComparable, ponieważ wymagają implementacji ogólnych i nietypowych)
• Osadzone elementy zewnętrzne P / Invoke i powiązane struktury.
• Finalizatory / destruktory (zwykle idzie w parze z IDisposable)
• Przechwytuje niezarządzaną pamięć / wskaźniki / kod „niebezpieczny”.