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

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

가요 :

• 공공 장소
• 개인 분야
• 속성
• 생성자
• 방법
  ?

품목 순서에 대해 단단하고 빠른 규칙이 있는지 궁금합니다. 나는 온통 종류입니다. 나는 어디에서나 할 수 있도록 특정 표준을 고수하고 싶다.

진짜 문제는 더 복잡한 속성이 메소드와 매우 비슷해 보이고 생성자보다 맨 앞에 위치하지 않는다는 것입니다.

팁 / 제안이 있습니까?

StyleCop 규칙 설명서 에 따르면 순서는 다음과 같습니다.

클래스, 구조체 또는 인터페이스 내에서 : (SA1201 및 SA1203)

• 상수 필드
• 필드
• 생성자
• 종료 자 (소멸자)
• 대의원
• 행사
• 열거 형
• 인터페이스 ( 인터페이스 구현 )
• 속성
• 인덱서
• 행동 양식
• 구조
• 클래스

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

• 공공의
• 내부의
• 내부 보호
• 보호
• 은밀한

각 액세스 그룹 내에서 정적 순서로 정렬 한 후 비 정적 순서로 정렬 (SA1204)

• 공전
• 비 정적

각 정적 / 비 정적 필드 그룹 내에서 읽기 전용, 비 읽기 전용 순서 : (SA1214 및 SA1215)

• 읽기 전용
• 비 읽기 전용

풀린 목록의 길이는 130 줄이므로 여기서 풀지 않습니다. 풀린 메소드 부분은 다음과 같습니다.

• 공개 정적 메소드
• 공개 방법
• 내부 정적 메소드
• 내부 방법
• 보호 된 내부 정적 메소드
• 보호 된 내부 방법
• 보호 된 정적 메소드
• 보호 된 방법
• 개인 정적 메소드
• 개인적인 방법

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

가시성 또는 항목 유형 (필드, 속성, 방법 등)별로 그룹화하는 대신 기능별 그룹화는 어떻습니까?

이것은 오래되었지만 여전히 관련성이 높은 질문이므로 다음과 같이 추가하겠습니다. 이전에 읽었을 수도 있고 읽지 않았을 수도있는 클래스 파일을 열 때 가장 먼저 찾는 것은 무엇입니까? 필드? 속성? 나는 경험을 통해 거의 항상 생성자를 찾아 나간다는 것을 깨달았습니다. 가장 이해해야 할 것은이 객체가 어떻게 구성되어 있기 때문입니다.

따라서 클래스 파일에서 생성자를 먼저 배치하기 시작했으며 그 결과는 심리적으로 매우 긍정적이었습니다. 다른 많은 것들 후에 생성자를 넣는 표준 권장 사항은 불쾌감을 느낍니다.

C # 6의 다가오는 기본 생성자 기능은 생성자의 자연스러운 위치가 클래스의 최상위에 있다는 증거를 제공합니다. 실제로 기본 생성자는 열기 괄호 앞에도 지정됩니다.

이와 같이 재정렬이 얼마나 큰 차이가 있는지는 재밌습니다. using시스템 네임 스페이스를 사용하여 명령문을 정렬 하는 방법을 상기시킵니다 . Visual Studio의 "Organize Usings"명령이이 순서를 사용했습니다. 이제 usings는 알파벳순으로 정렬되며 시스템 네임 스페이스에 특별한 처리가 없습니다. 결과는 더 단순하고 깨끗하게 느껴집니다.

언어 또는 업계 표준에 대해서는 잘 모르지만 각 지역을 #region으로 묶어 순서대로 정리하는 경향이 있습니다.

문장 사용

네임 스페이스

수업

개인 회원

공공 재산

생성자

공개 방법

개인 방법

IDesign 의 코딩 표준 또는 Brad Abram 웹 사이트 에 나열된 표준을 사용하는 것이 좋습니다 . 그것들은 내가 찾은 최고의 두 가지입니다.

브래드는 이렇게 말할 것입니다 ...

클래스 멤버는 알파벳순으로 정렬되고 섹션 (필드, 생성자, 속성, 이벤트, 메소드, 개인 인터페이스 구현, 중첩 유형)으로 그룹화되어야합니다.

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

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

어쨌든 그것은 나에게 의미가 있습니다

StyleCop에서

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

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

일반적으로 다음 패턴을 따르려고합니다.

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

각 파트 (정적 및 인스턴스)는 다음 멤버 유형으로 구성됩니다.

• 연산자 (항상 정적 임)
• 필드 (생성자 전에 초기화 됨)
• 생성자
• 소멸자 ( 생성자를 따르는 전통입니다 )
• 속성
• 행동 양식
• 행사

그런 다음 멤버를 가시성별로 정렬합니다 (더 적게에서 더 잘 보이도록).

• 은밀한
• 내부의
• 내부 보호
• 보호
• 공공의

순서는 교리가 아닙니다. 간단한 클래스는 읽기가 쉽지만,보다 복잡한 클래스는 상황 별 그룹화가 필요합니다.

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

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

나는 이것이 스타일 경찰에 위배된다는 것을 알고 있으며 누군가 내가 인터페이스의 앞에 유형의 구현 세부 정보를 배치 해야하는 이유를 제시 할 수 있다면 나는 기꺼이 바꿀 것입니다. 현재 개인 멤버를 마지막으로 배치하는 것이 좋습니다.

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

가장 가까운 곳은 Brad Abrams의 "디자인 지침, 관리 코드 및 .NET Framework"( http://blogs.msdn.com/brada/articles/361363.aspx )입니다.

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

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

나는 생성자를 다음에 두는 경향이 있습니다.

내 일반적인 의견은 파일 당 하나의 클래스를 고수해야하며 클래스가 속성 대 메소드의 구성이 큰 관심사 일 정도로 충분히 클 경우 클래스는 얼마나 크며 어쨌든 리팩토링해야합니까? 여러 가지 우려를 나타내는가?

개인 필드를 생성자와 함께 맨 위에 놓고 공개 인터페이스 비트를 넣은 다음 개인 인터페이스 비트를 선호합니다.

또한 클래스 정의가 항목 순서를 크게 중요하게 정의 할 수있을 정도로 길면 클래스가 너무 크고 복잡하여 리팩터링해야한다는 코드 냄새 일 수 있습니다.

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

열거 형
선언
생성자 메서드를
재정의 함 이벤트 속성

어떤 식 으로든 언어를 강요하는 언어는 없습니다. 나는 가시성 (공개, 보호, 비공개)으로 사물을 그룹화하는 경향이 있으며 #regions를 사용하여 관련 사물을 속성, 방법 또는 기타에 관계없이 기능적으로 그룹화합니다. 건설 방법 (실제 ctor 또는 정적 팩토리 기능)은 고객이 알아야 할 첫 번째 항목이므로 일반적으로 맨 위에 있습니다.

나는 이것이 오래된 것을 알고 있지만 내 순서는 다음과 같습니다.

공개, 보호, 개인, 내부, 추상 순서

• 상수
• 정적 변수
• 필드
• 행사
• 생성자
• 행동 양식
• 속성
• 대의원

또한 (속기 접근 방식 대신) 이와 같은 속성을 작성하고 싶습니다.

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