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

Czy istnieją oficjalne wytyczne C # dotyczące kolejności przedmiotów pod względem struktury klas?

Czy to idzie:

• Pola publiczne
• Pola prywatne
• Nieruchomości
• Konstruktory
• Metody
  ?

Jestem ciekawy, czy istnieje twarda i szybka zasada dotycząca kolejności przedmiotów? Jestem trochę w tym miejscu. Chcę trzymać się określonego standardu, aby móc to zrobić wszędzie.

Prawdziwy problem polega na tym, że moje bardziej złożone właściwości wyglądają bardzo podobnie do metod i czują się nie na miejscu na szczycie przed konstruktorem.

Wszelkie wskazówki / sugestie?

Zgodnie z dokumentacją reguł StyleCop kolejność jest następująca.

W obrębie klasy, struktury lub interfejsu: (SA1201 i SA1203)

• Stałe pola
• Pola
• Konstruktory
• Finalizatory (Destructors)
• Delegaci
• Wydarzenia
• Enums
• Interfejsy ( implementacje interfejsu )
• Nieruchomości
• Indeksujący
• Metody
• Struktury
• Klasy

W ramach każdej z tych grup uporządkuj według dostępu: (SA1202)

• publiczny
• wewnętrzny
• chronione wewnętrznie
• chroniony
• prywatny

W obrębie każdej grupy dostępu uporządkuj według statycznych, a następnie niestatycznych: (SA1204)

• statyczny
• niestatyczna

W obrębie każdej statycznej / niestatycznej grupy pól, uporządkuj tylko do odczytu, a następnie nie do odczytu: (SA1214 i SA1215)

• tylko czytać
• nie tylko do odczytu

Rozwinięta lista ma 130 linii, więc nie rozwinę jej tutaj. Metoda rozwinięta część to:

• publiczne metody statyczne
• metody publiczne
• wewnętrzne metody statyczne
• metody wewnętrzne
• chronione wewnętrzne metody statyczne
• chronione metody wewnętrzne
• chronione metody statyczne
• metody chronione
• prywatne metody statyczne
• metody prywatne

Dokumentacja zauważa, że ​​jeśli zalecana kolejność nie jest odpowiednia - powiedzmy, że wdrażanych jest wiele interfejsów, a metody interfejsu i właściwości powinny być pogrupowane razem - użyj częściowej klasy, aby pogrupować powiązane metody i właściwości.

Zamiast grupować według widoczności lub według rodzaju elementu (pole, właściwość, metoda itp.), A co z grupowaniem według funkcjonalności?

To jest stare, ale wciąż bardzo aktualne pytanie, więc dodam to: Jakiej pierwszej rzeczy szukasz, kiedy otworzysz plik zajęć, który mógłeś przeczytać wcześniej? Pola? Nieruchomości? Z doświadczenia zdałem sobie sprawę, że prawie niezmiennie idę polować na konstruktorów, ponieważ najbardziej podstawową rzeczą do zrozumienia jest to, jak ten obiekt jest zbudowany.

Dlatego zacząłem umieszczać konstruktory na pierwszym miejscu w plikach klas, a wynik był psychologicznie bardzo pozytywny. Standardowa rekomendacja umieszczania konstruktorów po szeregu innych rzeczy wydaje się dysonansowa.

Nadchodząca funkcja głównego konstruktora w C # 6 dostarcza dowodów, że naturalne miejsce dla konstruktora znajduje się na samym szczycie klasy - w rzeczywistości podstawowe konstruktory są określone nawet przed otwartym nawiasem klamrowym.

To zabawne, jak wielką różnicę sprawia takie zamawianie. Przypomina mi to, jak usingkiedyś zamawiano instrukcje - najpierw z przestrzeniami nazw Systemu. Polecenie „Organize Usings” programu Visual Studio używało tej kolejności. Teraz usings są tylko uporządkowane alfabetycznie, bez specjalnego traktowania przestrzeni nazw Systemu. Rezultat jest po prostu prostszy i czystszy.

Nie znam standardu językowego ani branżowego, ale zwykle układam rzeczy w tej kolejności, a każda sekcja jest zawinięta w #region:

za pomocą instrukcji

Przestrzeń nazw

Klasa

Członkowie prywatni

Nieruchomości publiczne

Konstruktory

Metody publiczne

Metody prywatne

Poleciłbym stosowanie standardów kodowania IDesign lub wymienionych na stronie internetowej Brada Abrama . To są najlepsze dwa, jakie znalazłem.

Brad powiedziałby ...

Członek klas powinien być alfabetycznie i pogrupowany w sekcje (pola, konstruktory, właściwości, zdarzenia, metody, implementacje prywatnego interfejsu, typy zagnieżdżone)

Jak wspomniano wcześniej, w języku C # nie ma nic, co dyktuje układ, osobiście używam regionów i robię coś takiego dla przeciętnej klasy.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

W każdym razie ma to dla mnie sens

From StyleCop

pola prywatne, pola publiczne, konstruktory, właściwości, metody publiczne, metody prywatne

Ponieważ StyleCop jest częścią procesu kompilacji MS, można to uznać za de facto standard

Zwykle staram się postępować według następnego wzoru:

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

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

• operatory (zawsze są statyczne)
• pola (zainicjowane przed konstruktorami)
• konstruktory
• destruktor ( jest tradycją podążania za konstruktorami )
• nieruchomości
• metody
• wydarzenia

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

• prywatny
• wewnętrzny
• wewnętrzny chroniony
• chroniony
• publiczny

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

Preferuję sortowanie według rodzaju, a następnie zmniejszanie 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 narusza to Style Copa i jeśli ktoś może podać mi dobry powód, dla którego powinienem umieścić szczegóły implementacji typu przed jego interfejsem, jestem gotów to zmienić. Obecnie zdecydowanie wolę umieszczać członków prywatnych na końcu.

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

Najbliżej można znaleźć „Wytyczne projektowe, kod zarządzany i .NET Framework” ( http://blogs.msdn.com/brada/articles/361363.aspx ) autorstwa Brada Abramsa

Wiele standardów jest tu opisanych. Odpowiednia sekcja to 2.8.

jedyne wskazówki dotyczące kodowania, jakie widziałem w tym zakresie, to umieszczenie pól na początku definicji klasy.

zwykle stawiam konstruktorów w następnej kolejności.

mój ogólny komentarz byłby taki, że powinieneś trzymać się jednej klasy na plik, a jeśli klasa jest na tyle duża, że ​​organizacja właściwości w stosunku do metod jest dużym problemem, jak duża jest klasa i czy powinieneś ją zrefaktoryzować? czy to dotyczy wielu problemów?

Wolę umieszczać pola prywatne u góry razem z konstruktorami, potem umieszczać bity interfejsu publicznego, a potem bity interfejsu prywatnego.

Ponadto, jeśli twoja definicja klasy jest wystarczająco długa, aby porządkowanie przedmiotów miało duże znaczenie, prawdopodobnie jest to zapach kodu wskazujący, że twoja klasa jest zbyt obszerna i złożona, i powinieneś zreformować.

Utrzymuję to tak proste, jak to możliwe (przynajmniej dla mnie)

Wyliczenia
Deklaracje
Konstruktory
Zastępują
Metody
Właściwości
Moduł obsługi zdarzeń

Z pewnością w języku nie ma niczego, co by to wymuszało. Staram się grupować rzeczy według widoczności (publiczne, następnie chronione, a następnie prywatne) i używam #regions do grupowania powiązanych funkcji funkcjonalnie, niezależnie od tego, czy jest to właściwość, metoda, czy cokolwiek innego. Metody konstrukcyjne (czy to rzeczywiste liczniki, czy statyczne funkcje fabryczne) są zwykle na pierwszym miejscu, ponieważ są pierwszą rzeczą, o której klienci powinni wiedzieć.

Wiem, że to stare, ale moje zamówienie wygląda następująco:

w kolejności publicznej, chronionej, prywatnej, wewnętrznej, abstrakcyjnej

• Stałe
• Zmienne statyczne
• Pola
• Wydarzenia
• Konstruktor (y)
• Metody
• Nieruchomości
• Delegaci

Lubię też pisać takie właściwości (zamiast skróconego podejścia)

// 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; }
}