일반적으로 클래스 영역을 어떻게 레이아웃합니까?

수업 지역을 배치하기위한 표준이 있는지 궁금했습니다.

나는 현재

Fields
Constructor
Properties
Public Methods
Private Methods

Fields개인 재산 및 Properties공공 재산 . 필자는 일반적으로 필요한 경우 하위 영역을 사용하거나 때때로 인터페이스 또는 baseClass 멤버와 같은 다른 영역을 추가합니다.

클래스 관련 열거 형 또는 때때로 구조체 / 순수 데이터 클래스 (실제 클래스 정의 이상)

--- 클래스 정의 ---

개인 회원

언어에 DTOR가있는 경우 CTOR / DTOR

공공 재산

유틸리티 방법 (소규모의 개인 또는 보호 된 방법)

수업 기능 (클래스 범위에 따라 여러 지역으로 나 ay 수 있음).

하위 지역? 수업에 단일 책임이 있습니까? (내재적으로 ... 내 대답은 "특성, 생성자 및 메소드를 그룹화하는 것을 제외하고는 거의 모든 지역"입니다. 그러나 그때까지는 그렇게 많이 사용하지 않습니다)

난 그냥 당신이 일반적으로 수업 레이아웃이 아니라 "#regions"를 의미한다는 것을 확인하고 싶었습니다.

아무도 지역 사용을 피한다고 언급 한 것에 놀랐습니다. OP가 지역 배치에 대한 여론 조사를 원하지만 다른 관점을 높이고 싶습니다.

나는 지역을 피한다. 작업중 인 코드를보고 싶습니다. 찾고있는 것을 찾기가 어렵다면 코드 접기를 사용하고 비슷한 클래스 구성을 그룹화하십시오.

왜 지역을 싫어합니까? CTRL+M,L및 CTRL+M,O코드 폴딩 전환됩니다. 그러나 축소하면 전체 영역이 숨겨집니다. 메소드 / 속성 / 설명 만 축소하면됩니다.

지역이 너무 많으면 코드 냄새가 나고 수업이 너무 많은 일을하고 있습니다. Jeff Atwood는 읽을만한 가치가있는 지역 에 대한 좋은 소식을 제공합니다 .

#regions에서 내가 가장 좋아하는 인용문 :

아니요, #regions를 사용하지 않습니다. 그리고 아니요, 저는 테러리스트와 협상하지 않습니다. 입 닥쳐.

- 제프 애트우드

많은 프로그래머들이 그것들을 사용한다고 주장한다는 것을 알고 있습니다. 이 질문은 주관적입니다. 방금 대안을 제안 할 것이라고 생각했습니다.

언어마다 다릅니다. 필자는 델파이 코더이기 때문에 다음과 같은 델파이 표준 규칙을 따르는 경향이 있습니다.

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;

읽고 이해하기 쉬운 정보를 구성하는 좋은 방법입니다.

나는 다음과 같은 방법으로 배치하는 경향이 있습니다.

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

사용하는 언어를 사용하지 않았 Properties으므로 이것이 배치되지 않은 이유입니다. 다른 사람이 코드에서이 파일을 사용하는 경우 공개 메소드 인 API에만 관심을 가져야하기 때문에 개인 메소드와 필드를 맨 아래에 배치했습니다. 그리고 내가 아는 모든 텍스트 편집기, 심지어 IDE조차도 파일을 열 때 커서를 맨 위에 놓습니다.

그것은 나를 위해 판단 요청입니다. 가독성이 필요할 때 지역을 사용합니다.

또한 Visual Studio 색 구성표 (현재 진한 빨간색)에서 다른 색상을 사용하여 나머지 코드에서 눈에 띄게 만듭니다.

#region을 사용할 수있는 예 : 여러 줄의 XML 스 니펫이 필요한 단위 테스트에 대한 테스트 메소드를 작성하면 XML 문자열이 일반적인 들여 쓰기를 중단합니다 (왼쪽 여백을 따라 시작하므로) 추악함을 숨기려면 축소 할 수 있도록 #region에 래핑합니다.

Bob Martin의 Clean Code 책은 전체 5 장을 형식화에 전념합니다. 내가 그것을 훌륭하게 요약한다고 느끼는 몇 가지 핵심 사항이 있습니다.

• 가시성과 청결도에 따라 변수와 메소드를 그룹화하려는 대부분의 시도는 이해가되지 않으며 코드를 많이 탐색해야합니다.
• 서로를 수직으로 가깝게 호출하는 방법을 사용하면 탐색의 양이 줄어들고 물건을 쉽게 찾을 수 있습니다.
• "이 코드가 어느 지역에 속하는가?"를 멈추고 생각해야한다면, 당신의 생각은 깨지지 않을 것입니다. 몇 분마다.
• 인스턴스 변수는 일반적으로 적고 어디에서나 사용하기 쉬울 것이므로 찾기가 가장 쉬운 클래스의 최상위에 속합니다. 한 메소드에서만 사용되는 변수 및 선언은 해당 메소드 내에 존재해야합니다. 몇 가지 방법으로 만 사용하는 경우에는 수직으로 가까이 있어야하지만 사용하는 몇 가지 방법 위에 있어야합니다.

일반적으로 상호 작용하는 요소를 세로로 가깝게 배치하여 코드를 정렬하면 특정 영역을 만들 필요가 없습니다. 코드가 너무 길어서 영역에 많은 코드를 숨겨야하는 경우 클래스가 너무 많은 것을 시도하고 있음을 나타내는 코드 냄새 일 수 있습니다. 아마도 일부 기능은 유틸리티 클래스로 이동하거나 조상에게 푸시 될 수 있습니다.

코드가 너무 길거나 "못생긴"코드를 "숨겨야"하는 경우 영역 사용 여부보다 걱정해야 할 큰 문제가있을 수 있습니다. 개인적으로 나는 그것들을 사용할 필요가 없으며 다른 사람의 코드를 작업 할 때 항상 어쨌든 열어야한다는 것을 알았습니다. 왜 귀찮습니까?

나는 현재 다음과 같은 클래스를 레이아웃합니다 :

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

그런 다음 액세스 수준을 각 선언에 접두사로 지정합니다 (일부 액세스별로 그룹화 됨). 액세스로 최상위 그룹화를 수행했지만 언젠가는 위와 같이 작동하지 않는 시점을 모르겠습니다. 예를 들어 C ++ / CLI에서 (현재 강제로 사용해야합니다 :-() 당신은 이것을 할 수 있습니다. 그룹별로 엉망이됩니다.

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

루나틱 프린지 답변 : 적어도 C #에 관해서는 그렇지 않습니다. Visual Studio와 R # 사이에서 마술처럼 모든 멤버 또는 구현을 탐색 할 수 있으므로이 내용에 집착하지 않아도됩니다. 커서가있는 곳에 입력을 시작하십시오.

Wyatt 및 몇 가지 다른 답변과 마찬가지로 일반적으로 지역 사용을 피합니다. 지역에는 하나의 목적이 있습니다. 보고 싶지 않은 코드를 숨길 수 있습니다. 클래스에 많은 코드가 있으면 보지 않아도되므로 해당 코드를 축소 할 수있는 많은 영역이 필요합니다. 아마도 클래스에 코드가 너무 많습니다. ReSharper는 영역을 생성하지 않는 한 (인터페이스 구현을 위해) 새 코드를 배치 할 위치를 결정할 때 영역을 존중하지 않습니다.

내가 수용 할 수있는 영역의 한 가지 사용은 "피할 수없는 추악한"코드를 숨기는 것입니다. 현재 표준으로 내부적으로 잘 설계 될 수없는 특정 구현 세부 사항을 다루는 코드. 이것은 보통 고급 주니어 프로그래머가 작성하지 않은 고급 코드입니다. 이들은 다음과 같습니다.

• 특정 내장 인터페이스 구현 (IDisposable, IConvertible, 때로는 IEnumerable 또는 IComparable은 일반 및 비 일반 구현이 필요하므로)
• 임베디드 P / Invoke externs 및 관련 구조.
• 종료 자 / 소멸자 (일반적으로 IDisposable과 함께 제공)
• 비 관리 메모리 / 포인터 / "안전하지 않은"코드에 연결합니다.