클래스의 항목 순서:필드, 특성, 생성자, 메서드

클래스의 항목 순서:필드, 특성, 생성자, 메서드

클래스 구조의 항목 순서에 대한 공식적인 C# 지침이 있습니까?

작동합니까?

• 공용 필드
• 개인 필드
• 특성.
• 생성자
• 
  ?

품목 순서에 대한 엄격하고 빠른 규칙이 있는지 궁금합니다.제가 좀 정신이 없어요.저는 어디서나 할 수 있도록 특정한 기준을 고수하고 싶습니다.

진짜 문제는 저의 더 복잡한 속성들이 결국 메소드들과 많이 닮았고 그것들은 시공자보다 먼저 상단에 위치한 것처럼 느껴진다는 것입니다.

팁/제안이 있습니까?

StyleCop Rules Documentation에 따르면 주문은 다음과 같습니다.

클래스 내, 구조자 인터페이스: (SA1201 및 SA1203)

• 상수 필드
• 필드
• 생성자
• 피니시저(파괴자)
• 대표자
• 이벤트
• 열거형
• 인터페이스(인터페이스 구현)
• 특성.
• 인덱서
• 방법들
• 구조체
• 반

각 그룹 내에서 액세스별로 주문: (SA1202)

• 일반의
• 내부의
• 보호된 내부
• 보호된
• 사적인

각 액세스 그룹 내에서 정적 순으로 정렬한 다음 정적 순으로 정렬합니다(SA1204).

• 정적인
• 정적이 아닌

각 정적/비정적 필드 그룹 내에서 읽기 전용으로 정렬한 다음 읽기 전용으로 정렬합니다. (SA1214 및 SA1215)

• 읽기 전용
• 읽기 전용이 아닌

언롤링된 목록은 130줄 길이이므로 여기서 언롤링하지 않겠습니다.Methods(메소드) 부분은 다음과 같습니다.

• 공중 정태적 방법
• 공공의 방법
• 내부 정적 방법
• 내적인 방법
• 보호된 내부 정적 메서드
• 보호된 내부 방법
• 보호된 정적 메서드
• 보호된 방법
• 사설 정적 방법
• 사적인 방법

설명서에서는 지정된 순서가 적합하지 않은 경우(예: 여러 인터페이스가 구현되고 있으며 인터페이스 메서드와 속성을 함께 그룹화해야 하는 경우) 부분 클래스를 사용하여 관련 메서드와 속성을 함께 그룹화합니다.

가시성이나 항목 유형(필드, 속성, 방법 등)별로 그룹화하기보다는 기능별로 그룹화하는 것이 어떻습니까?

이 질문은 오래되었지만 여전히 매우 관련성이 높은 질문이므로 다음과 같이 추가하겠습니다.이전에 읽었거나 읽지 않았을 수 있는 클래스 파일을 열 때 가장 먼저 찾는 것은 무엇입니까?필드?속성?저는 경험을 통해 거의 항상 제가 건설자들을 사냥한다는 것을 깨달았습니다. 왜냐하면 가장 기본적으로 이해할 수 있는 것은 이 물체가 어떻게 만들어지는지이기 때문입니다.

그래서 저는 클래스 파일에 컨스트럭터를 우선시하기 시작했고, 그 결과는 심리적으로 매우 긍정적이었습니다.생성자를 여러 가지 다른 것 뒤에 배치하는 표준 권장 사항은 불협화음처럼 느껴집니다.

C# 6의 다가오는 기본 생성자 기능은 생성자를 위한 자연적인 장소가 클래스의 맨 위에 있다는 증거를 제공합니다. 사실 기본 생성자는 개방형 가새 이전에도 지정됩니다.

이런 재주문이 얼마나 큰 차이를 만드는지 재미있습니다.그것은 나에게 어떻게 생각나를 생각나게 합니다.using순서가 지정된 문 - 시스템 네임스페이스를 먼저 사용합니다.Visual Studio의 "Organize Usings" 명령은 이 순서를 사용했습니다.지금이다usings는 알파벳 순으로 정렬되며, 시스템 네임스페이스에 특별한 처리가 제공되지 않습니다.결과는 더 단순하고 깨끗하게 느껴집니다.

언어나 산업 표준에 대해서는 잘 모르지만 각 섹션을 #영역으로 묶은 다음과 같은 순서로 배열하는 경향이 있습니다.

문 사용

네임스페이스

학급

개인 회원

공공 재산

생성자

공개 방법

개인 방법

ID Design(웹 아카이브)의 코딩 표준이나 Brad Abram의 웹사이트에 나열된 표준을 사용하는 것을 추천합니다.그것들이 제가 찾은 최고의 두 개입니다.

브래드가 말하길...

클래스 구성원은 알파벳 순으로 지정하고 섹션(필드, 생성자, 속성, 이벤트, 메서드, 개인 인터페이스 구현, 중첩 유형)으로 그룹화해야 합니다.

앞서 언급했듯이 C# 언어에는 레이아웃을 지시하는 것이 없으며, 저는 개인적으로 지역을 사용하며, 평균적인 수업을 위해 이와 같은 일을 합니다.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

어쨌든 이해가 됩니다.

보통 저는 다음 패턴을 따르려고 노력합니다.

• 정적 멤버(일반적으로 다른 컨텍스트, 스레드 안전해야 함 등)
• 인스턴스 멤버

각 부품(정적 및 인스턴스)은 다음 멤버 유형으로 구성됩니다.

• 연산자(항상 정적)
• 필드(생성자 이전에 초기화됨)
• 건설업자들
• 파괴자(생성자를 따르는 전통)
• 특성.
• 방법들
• 사건들

그런 다음 구성원이 가시성별로 정렬됩니다(덜 보이는 것에서 더 잘 보이는 것으로 정렬됨).

• 사적인
• 내부의
• 내부적으로 보호를 받는
• 보호된
• 일반의

순서는 독단적이지 않습니다. 단순 클래스는 읽기 쉽지만, 더 복잡한 클래스는 상황별 그룹화가 필요합니다.

제가 선호하는 것은 종류별로 주문한 후 다음과 같이 가시성을 낮추는 것입니다.

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

저는 이것이 Style Cop을 위반한다는 것을 알고 있으며, 만약 누군가가 제가 인터페이스 앞에 유형의 구현 세부사항을 배치해야 하는 이유를 알려줄 수 있다면, 저는 기꺼이 변경할 것입니다.현재 저는 개인 회원을 마지막에 두는 것을 선호합니다.

참고: 공용 또는 보호된 필드를 사용하지 않습니다.

스타일캅에서

개인 필드, 공용 필드, 생성자, 속성, 공용 메서드, 개인 메서드

StyleCop은 MS 빌드 프로세스의 일부이므로 이를 사실상의 표준으로 볼 수 있습니다.

가장 가까운 것은 "디자인 가이드라인, 관리 코드 및 .NET 프레임워크"(http://blogs.msdn.com/brada/articles/361363.aspx) by Brad Abrams)입니다.

여기에는 많은 표준이 설명되어 있습니다.관련 섹션은 2.8이라고 생각합니다.

저는 생성자와 함께 개인 필드를 맨 위에 올린 다음 공용 인터페이스 비트를 넣고 개인 인터페이스 비트를 놓는 것을 선호합니다.

또한 항목 순서가 중요할 정도로 클래스 정의가 길면 클래스가 너무 부피가 크고 복잡하다는 것을 나타내는 코드 냄새일 수 있으므로 리팩터링해야 합니다.

나는 그것을 가능한 한 단순하게 유지합니다 (적어도 나는)

정보입니다.
핸들러

오래된 것으로 알고 있습니다만, 제 주문은 다음과 같습니다.

공개, 보호, 비공개, 내부, 추상 순으로

• 상수
• 정적 변수
• 필드
• 이벤트
• 생성자
• 방법들
• 특성.
• 대표자

저는 또한 이런 속성을 쓰는 것을 좋아합니다(단수 접근법 대신).

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

이것에 대해 제가 제안한 유일한 코딩 지침은 클래스 정의의 맨 위에 필드를 넣는 것입니다.

저는 다음으로 건설자를 꼽는 경향이 있습니다.

제 일반적인 의견은 당신이 파일당 하나의 클래스를 고수해야 한다는 것이고, 만약 클래스가 충분히 커서 속성 대 방법의 조직이 큰 관심사라면, 클래스는 얼마나 크고 당신은 어쨌든 그것을 리팩터링해야 합니까?여러 가지 우려 사항을 나타냅니까?

언어에는 확실히 어떤 방식으로든 그것을 강제하는 것은 없습니다.저는 가시성(공개, 보호, 비공개)별로 그룹화하고 #regions를 사용하여 속성, 방법 등에 관계없이 관련 항목을 기능적으로 그룹화하는 경향이 있습니다.시공 방법(실제 cctor 또는 정적 공장 기능)은 고객이 가장 먼저 알아야 할 사항이기 때문에 일반적으로 맨 위에 있습니다.

저는 더 나은 레이아웃이라고 생각하는 것에 대해 승인된 답변을 재구성했습니다.

클래스, 구조체 또는 인터페이스 내:

• 상수 필드
• 읽기 전용 필드
• 필드
• 이벤트
• 특성.
• 인덱서
• 생성자
• 피니시저(파괴자)
• 인터페이스(인터페이스 구현)
• 방법들
• 반
• 구조체
• 열거형
• 대표자

각 그룹 내에서 액세스별로 정렬:

• 일반의
• 내부의
• 보호된 내부
• 보호된
• 사적인

각 액세스 그룹 내에서 정적 순으로 정렬한 다음 정적 순으로 정렬합니다.

• 정적인
• 정적이 아닌

또한 중첩된 유형은 최소한으로 유지되어야 한다고 생각합니다.저는 종종 사람들이 별도의 인스턴스가 되는 것이 더 나을 중첩된 클래스, 열거형, 대리인을 갖는 것을 봅니다.유형을 중첩하여 만드는 것은 거의 이득이 없습니다.또한 별도의 파일로 저장합니다.5개의 클래스가 있는 파일은 나에게 어수선하게 느껴집니다.

언급URL : https://stackoverflow.com/questions/150479/order-of-items-in-classes-fields-properties-constructors-methods