Kolejność elementów w klasach: pola, właściwości, konstruktory, metody

Zamiast grupować po widoczności lub po typie elementu (pole, właściwość, metoda itp.), a może Grupowanie według funkcjonalności?

Polecam korzystanie ze standardów kodowania z IDesign lub tych wymienionych na stronie Brada Abrama . To najlepsze dwa, jakie znalazłem.

Brad by powiedział...

Klasy powinny być Alfabetycznie ułożone i pogrupowane w sekcje (pola, konstruktory, właściwości, zdarzenia, metody, implementacje prywatnych interfejsów, typy zagnieżdżone)

Jest to stare, ale wciąż bardzo istotne pytanie, więc dodam: co jest pierwszą rzeczą, której szukasz, gdy otwierasz plik klasy, który być może wcześniej przeczytałeś lub nie? Pola? Nieruchomości? Z doświadczenia zdałem sobie sprawę, że prawie zawsze poluję na konstruktorów, ponieważ najbardziej podstawową rzeczą do zrozumienia jest to, jak ten obiekt jest zbudowany.

Dlatego zacząłem stawiać konstruktory na pierwszym miejscu w klasowych plikach, a wynik był psychologicznie bardzo tak. Standardowe zalecenie stawiania konstruktorów za kilkoma innymi rzeczami wydaje się dysonansowe.

Nadchodząca funkcja głównego konstruktora w C# 6 dostarcza dowodów na to, że naturalne miejsce dla konstruktora jest na samym szczycie klasy - w rzeczywistości podstawowe konstruktory są określone nawet przed nawiasami otwartymi.

Nie znam się na języku czy standardzie branżowym, ale zazwyczaj układam rzeczy w tej kolejności z każdą sekcją zawiniętą w # region:

Using Statements

Przestrzeń nazw

Klasa

Członkowie prywatni

Public properties

Konstruktory

Metody publiczne

Metody prywatne

Jak już wcześniej wspomniałem, w języku C# nie ma nic, co dyktowałoby układ, ja osobiście używam regionów i robię coś takiego dla klasy średniej.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

It makes sense to me anyway

From StyleCop

Private fields, public fields, constructors, properties, public methods, private methods

Jako, że StyleCop jest częścią procesu MS build, możesz to zobaczyć jako de facto standard

Zazwyczaj staram się podążać za następnym wzorcem:

• statyczne elementy (mają zwykle inny kontekst, muszą być bezpieczne dla wątku itp.)
• Członkowie instancji

Każda część (statyczna i instancyjna) składa się z następujących typów elementów:

• operatory (są zawsze statyczne)
• pola (inicjowane przed konstruktorami)
• konstruktorzy
• destructor (to tradycja podążania za konstruktorzy )
• właściwości
• metody
• Wydarzenia

Następnie członkowie są sortowane według widoczności (od mniej do bardziej widocznych):

• private
• Wewnętrzny
• wewnętrzna ochrona
• protected
• public

Kolejność nie jest dogmatem: proste klasy są łatwiejsze do odczytania, jednak bardziej złożone klasy wymagają grupowania kontekstowego.

Najbliżej znajdziesz " wytyczne projektowe, zarządzany kod i. NET Framework "( http://blogs.msdn.com/brada/articles/361363.aspx ) by Brad Abrams

Przedstawiono tu wiele standardów. Odpowiednia sekcja to chyba 2.8.

Moje preferencje to uporządkowanie według rodzaju, a następnie zmniejszenie widoczności w następujący sposób

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

Wiem, że to narusza styl Cop i jeśli ktoś może mi podać dobry powód, dla którego powinienem umieścić szczegóły implementacji typu przed jego interfejsem, to jestem skłonny zmienić. Obecnie zdecydowanie preferuję umieszczanie prywatnych członków na ostatnim miejscu.

Uwaga: nie używam pól publicznych ani chronionych.

Jedyne wytyczne kodowania, które widziałem sugerowane dla tego jest umieszczenie pól na górze definicji klasy.

Mam tendencję do stawiania konstruktorów obok.

Mój ogólny komentarz byłby taki, że powinieneś trzymać się jednej klasy na plik i jeśli klasa jest na tyle duża, że organizacja właściwości kontra metody jest dużym problemem, jak duża jest klasa i czy i tak powinieneś ją refaktoryzować? czy reprezentuje wiele obaw?

Wolę umieścić prywatne pola na górze wraz z konstruktorem (konstruktorami), następnie umieścić publiczne bity interfejsu, a następnie prywatne bity interfejsu.

Ponadto, jeśli twoja definicja klasy jest wystarczająco długa, aby kolejność przedmiotów miała duże znaczenie, prawdopodobnie jest to zapach kodu wskazujący, że twoja klasa jest zbyt nieporęczna i złożona i powinieneś refaktorować.

I keep it as simple as possible (for me at least)

Wyliczenia
Deklaracje
Konstruktorzy
Overrides
Metody
Właściwości
Event Handler

Z pewnością nie ma w języku nic, co by go w jakikolwiek sposób wymusiło. Mam tendencję do grupowania rzeczy według widoczności (publicznej, potem chronionej, potem prywatnej) i używam #regions do grupowania powiązanych rzeczy funkcjonalnie, niezależnie od tego, czy jest to właściwość, metoda, czy cokolwiek innego. Metody konstrukcyjne (czy rzeczywiste ctor lub statyczne funkcje fabryczne) są zwykle na szczycie, ponieważ są pierwszą rzeczą, o której klienci muszą wiedzieć.

Wiem, że to jest stare, ale mój rozkaz jest następujący:

W porządku publicznym, chronionym, prywatnym, wewnętrznym, abstrakcyjnym

• stałe
• Zmienne Statyczne
• pola
• Wydarzenia
• Konstruktor(y)
• metody
• Właściwości
• delegaci

Lubię też wypisywać takie właściwości (zamiast podejścia stenograficznego)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}