코드 냄새는 잠재적으로 버그의 수를 증가시키는 디자인에 문제가 있음을 나타내는 증상입니다. 이는 지역의 경우에는 해당되지 않지만 지역은 긴 방법처럼 코드 냄새를 유발할 수 있습니다.

이후:

반 패턴 (또는 반 패턴)은 일반적으로 사용될 수 있지만 실제로는 비 효과적이고 반 생산적인 사회 또는 비즈니스 운영 또는 소프트웨어 엔지니어링에 사용되는 패턴입니다.

영역 은 안티 패턴입니다. 코드의 품질이나 가독성을 높이 지 않는 더 많은 작업이 필요하므로 버그 수를 줄이지 않으며 코드를 리팩토링하기가 더 복잡해질 수 있습니다.

메소드 안에 영역을 사용하지 마십시오. 대신 리팩터링

방법은 짧아야 합니다. 메소드에 10 개의 행만있는 경우 다른 5 개에서 작업 할 때 영역을 사용하여 5 개를 숨기지 않을 수 있습니다.

또한 각 메소드는 하나만 수행해야합니다 . 반면에 지역은 다른 것을 분리 하기위한 것 입니다. 방법이 A, B를 수행하는 경우 두 영역을 만드는 것이 논리적이지만 잘못된 접근 방식입니다. 대신 메소드를 두 개의 개별 메소드로 리팩토링해야합니다.

이 경우 영역을 사용하면 리팩토링이 더 어려워 질 수 있습니다. 당신이 가지고 있다고 상상해보십시오 :

private void DoSomething()
{
    var data = LoadData();
    #region Work with database
    var verification = VerifySomething();
    if (!verification)
    {
        throw new DataCorruptedException();
    }

    Do(data);
    DoSomethingElse(data);
    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine();
    auditEngine.Submit(data);
    #endregion
}

첫 번째 영역을 축소하여 두 번째 영역에 집중하는 것은 위험 할뿐만 아니라 흐름을 중지하는 예외를 잊어 버릴 수 있습니다 ( return대신 가드 조항이있을 수 있으므로 더 찾기가 어렵습니다) 코드를 이런 식으로 리팩토링해야하는 경우 :

private void DoSomething()
{
    var data = LoadData();
    #region Work with database
    var verification = VerifySomething();
    var info = DoSomethingElse(data);

    if (verification)
    {
        Do(data);
    }

    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine(info);
    auditEngine.Submit(
        verification ? new AcceptedDataAudit(data) : new CorruptedDataAudit(data));
    #endregion
}

이제 영역은 의미가 없으며 첫 번째 영역의 코드를 보지 않고 두 번째 영역의 코드를 읽고 이해할 수 없습니다.

때때로 내가 본 또 다른 경우는 다음과 같습니다.

public void DoSomething(string a, int b)
{
    #region Validation of arguments
    if (a == null)
    {
        throw new ArgumentNullException("a");
    }

    if (b <= 0)
    {
        throw new ArgumentOutOfScopeException("b", ...);
    }
    #endregion

    #region Do real work
    ...
    #endregion
}

인수 유효성 검사가 수십 개의 LOC에 걸쳐 시작될 때 영역을 사용하고 싶어하지만 .NET Framework 소스 코드에서 사용되는이 문제를 해결하는 더 좋은 방법이 있습니다.

public void DoSomething(string a, int b)
{
    if (a == null)
    {
        throw new ArgumentNullException("a");
    }

    if (b <= 0)
    {
        throw new ArgumentOutOfScopeException("b", ...);
    }

    InternalDoSomething(a, b);
}

private void InternalDoSomething(string a, int b)
{
    ...
}

메소드 외부의 영역을 사용하여 그룹화하지 마십시오

• 어떤 사람들은 그것들을 사용하여 필드, 속성 등을 함께 그룹화합니다. 이 접근법은 잘못되었습니다. 코드가 StyleCop 호환 인 경우 필드, 속성, 개인 메서드, 생성자 등이 이미 그룹화되어 찾기 쉽습니다. 그렇지 않다면 코드베이스 전체에 균일 성을 보장하는 규칙 적용에 대해 생각할 시간입니다.

• 다른 사람들은 영역을 사용 하여 유사한 엔티티를 많이 숨 깁니다 . 예를 들어, 수백 개의 필드가있는 클래스 (주석과 공백을 세면 최소 500 줄의 코드 작성)가있는 경우 해당 필드를 영역 안에 넣고 축소하여 잊어 버리려는 유혹을받을 수 있습니다. 다시 말하지만, 당신은 잘못하고 있습니다 : 클래스에 너무 많은 필드가 있으므로 상속을 사용하거나 객체를 여러 객체로 슬라이스하는 것에 대해 더 잘 생각해야합니다.

• 마지막으로 일부 사람들은 영역을 사용 하여 관련 항목 을 그룹화 하려는 유혹을받습니다 . 델리게이트와의 이벤트 또는 IO와 관련된 다른 방법과의 IO 관련 방법 등. 첫 번째 경우, 유지하기 어려운 혼란이됩니다. 읽고 이해하십시오. 두 번째 경우, 더 나은 디자인은 아마도 여러 클래스를 만드는 것입니다.

지역에 잘 사용됩니까?

아니요 . 레거시 사용이있었습니다 : 생성 된 코드. 그럼에도 불구하고 코드 생성 도구는 부분 클래스를 대신 사용해야합니다. C #에 지역 지원이있는 경우 대부분 레거시 사용으로 인해 발생하고 너무 많은 사람들이 코드에 지역을 사용했기 때문에 기존 코드베이스를 손상시키지 않으면 서 지역을 제거 할 수 없습니다.

에 대해 생각하십시오 goto. 언어 나 IDE가 기능을 지원한다고해서 매일 사용해야한다는 의미는 아닙니다. StyleCop SA1124 규칙은 명확합니다. 영역을 사용해서는 안됩니다. 못.

예

현재 동료의 코드를 코드 검토하고 있습니다. 코드베이스에는 많은 지역이 포함되어 있으며 실제로 지역을 사용하지 않는 방법과 지역이 나쁜 코드로 이어지는 이유의 완벽한 예입니다. 여기 몇 가지 예가 있어요.

4 000 LOC 몬스터 :

최근 Programmers.SE 어딘가에서 파일을 너무 많이 포함 할 때 using( “사용하지 않은 사용 제거”명령을 실행 한 후)이 파일 내부의 클래스가 너무 많이 수행되고 있음을 나타내는 좋은 신호입니다. 파일 자체의 크기에도 동일하게 적용됩니다.

코드를 검토하는 동안 4 000 LOC 파일을 발견했습니다. 이 코드의 작성자는 단순히 15 줄의 동일한 메소드를 수백 번 복사하여 붙여 넣은 것으로 나타 났으며 변수의 이름과 호출 된 메소드를 약간 변경했습니다. 간단한 정규 표현식을 사용하면 몇 가지 제네릭을 추가하여 파일을 4 000 LOC에서 500 LOC로 트리밍 할 수있었습니다. 좀 더 영리한 리팩토링을 사용하면이 클래스가 수십 줄로 줄어들 수 있습니다.

지역을 사용함으로써 저자는 코드를 유지 관리하는 것이 불가능하고 잘못 작성되었다는 사실을 무시하고 코드를 리팩토링하는 대신 코드를 크게 복제하도록 권장했습니다.

지역“Do A”, 지역“Do B”:

또 다른 훌륭한 예로는 단순히 작업 1, 작업 2, 작업 3 등을 수행 한 괴물 초기화 방법이 있습니다. 각각 독립적으로 5 ~ 6 개의 작업이있었습니다. 각 작업은 컨테이너 클래스에서 무언가를 초기화합니다. 이러한 모든 작업은 하나의 방법으로 그룹화되고 지역으로 그룹화되었습니다.

이것은 한 가지 장점이있었습니다.

• 이 방법은 지역 이름을보고 이해하기가 매우 분명했습니다. 다시 말해 리팩토링 된 동일한 방법은 원래 방법과 동일합니다.

반면에 문제는 여러 가지였습니다.

• 지역간에 종속성이 있는지는 확실하지 않았습니다. 바라건대, 변수 재사용은 없었습니다. 그렇지 않으면 유지 관리가 훨씬 악몽이 될 수 있습니다.

• 이 방법은 테스트하기가 거의 불가능했습니다. 한 번에 20 가지를 수행하는 방법이 올바르게 수행되는지 어떻게 쉽게 알 수 있습니까?

필드 영역, 속성 영역, 생성자 영역 :

검토 된 코드에는 모든 필드, 모든 속성 등을 그룹화하는 많은 영역이 포함되어 있습니다. 이는 명백한 문제인 소스 코드 증가입니다.

파일을 열고 방대한 필드 목록을 보면 클래스를 먼저 리팩터링 한 다음 코드를 사용하는 경향이 있습니다. 지역에서는 물건을 무너 뜨리고 잊어 버리는 습관이 있습니다.

또 다른 문제는 모든 곳에서 수행하면 하나의 블록 영역을 만드는 것입니다. 이것은 실제로 내가 검토 한 코드에서 #region Constructor하나의 생성자 를 포함하는 많은 경우였습니다 .

마지막으로 필드, 속성, 생성자 등 은 이미 순서대로되어 있어야 합니다. 그것들이 관례 (대문자로 시작하는 상수 등)와 일치하면 요소의 유형이 멈추고 다른 시작 부분이 이미 분명하므로 명확하게 영역을 만들 필요가 없습니다.

---

답변