문제

Visual Studio 환경에서 코드를 #regions로 래핑하는 것에 대해 어떻게 생각하시나요?(또는 다른 IDE에 비슷한 것이 있는 경우...)

도움이 되었습니까?

해결책

10번 중 9번은 코드 폴딩이 실패했음을 의미합니다. SoC 원리 그 가치가 무엇인지.
나는 부분 수업에 대해서도 거의 같은 느낌을 받습니다.너무 크다고 생각되는 코드 조각이 있는 경우 숨기거나 분할하지 말고 관리 가능하고 재사용 가능한 부분으로 잘라야 합니다.
다음에 누군가 변경해야 할 때 문제가 될 것이며 250줄의 괴물 메소드에 숨겨진 논리를 볼 수 없습니다.

가능할 때마다 기본 클래스에서 일부 코드를 가져와 도우미 또는 팩토리 클래스로 가져옵니다.

foreach (var item in Items)
{
    //.. 100 lines of validation and data logic..
}

처럼 읽을 수 없습니다

foreach (var item in Items)
{
    if (ValidatorClass.Validate(item))
        RepositoryClass.Update(item);
}



어쨌든 내 $ 0.02.

다른 팁

이거 에 얘기됐지 코딩 호러.

내 개인적인 믿음은 그것들이 유용하지만, 너무 과하면 너무 과할 수 있다는 것입니다.

나는 이를 사용하여 코드 블록을 다음과 같이 주문합니다.
열거
선언
생성자
행동 양식
이벤트 핸들러
속성

때로는 #regions가 권장되거나 요구되는 팀에서 일하는 자신을 발견할 수도 있습니다.당신이 나와 같고 접힌 코드를 가지고 장난치는 것을 참을 수 없다면 C#에 대한 개요를 끌 수 있습니다.

  1. 옵션 -> 텍스트 편집기 -> C# -> 고급 탭
  2. "파일이 열릴 때 개요 모드 시작"을 선택 취소하십시오.

나는 #Region을 사용하여 부분 클래스의 자동 생성된 부분에 실제로 속하는 추악하고 쓸모없는 자동 생성 코드를 숨겼습니다.그러나 오래된 프로젝트나 업그레이드된 프로젝트로 작업할 때 항상 그런 여유가 있는 것은 아닙니다.

다른 유형의 접기는 항상 Functions를 접습니다.함수 이름을 잘 지정하면 무언가를 테스트하거나 (다시) 작성하지 않는 한 내부를 볼 필요가 없습니다.

Jeff 등의 문제를 이해하는 동안.알.내가 지역에 대해 가지고 있는 것 ~하지 않다 왜 때리는지 이해해 CTRL 키+,CTRL 키+ 파일의 모든 영역을 확장하는 것은 처리하기가 너무 어렵습니다.

나는 사용한다 텍스트메이트 (Mac만 해당) 코드 접기가 있고 접는 기능에 정말 유용하다고 생각합니다. "getGet" 기능이 무엇인지 알고 있으므로 10줄의 귀중한 화면 공간을 차지할 필요가 없습니다.

동일한 코드를 두 번 표시하지 않기 위해 다른 사람에게 코드를 표시하지 않는 한 for 루프, if 문 또는 이와 유사한 것을 숨기는 데 사용하지 않습니다.

나는 지역이 아닌 부분 수업을 선호합니다.

다른 사람들이 지역을 광범위하게 사용하는 것도 어딘가에서 누군가가 단일 책임 원칙을 위반하고 하나의 개체로 너무 많은 일을 하려고 한다는 인상을 줍니다.

@

코드 생성이 완료된 후 도구 자동 생성 코드를 사용자 정의에서 분리할 수 있도록 부분 클래스가 제공됩니다.이는 codegen을 다시 실행한 후에도 코드가 그대로 유지되고 덮어쓰여지지 않음을 의미합니다.이것은 좋은 일입니다.

나는 부분적인 수업을 좋아하지 않습니다. 저는 각 수업이 담당하는 매우 명확하고 단일한 문제를 갖도록 수업을 개발하려고 노력합니다.그러기 위해서는 명확한 책임이 있는 것을 여러 파일로 나누어야 한다고는 생각하지 않습니다.그래서 나는 부분수업을 좋아하지 않는다.

그렇게 말하면 나는 지역에 관해 울타리를 치고 있습니다.대부분의 경우에는 사용하지 않습니다.그러나 나는 매일 영역을 포함하는 코드를 사용하여 작업합니다. 어떤 사람들은 코드를 너무 무겁게 사용하고(개인 메서드를 영역으로 접은 다음 각 메서드를 자신의 영역으로 접음) 어떤 사람들은 가볍게 사용합니다(열거형을 접고, 속성 접기 등).현재로서는 (a) 데이터가 정적으로 유지될 가능성이 높거나 (열거형과 같이) 자주 건드리지 않을 경우, 또는 (b) 다음과 같은 메소드가 있는 경우에만 코드를 영역에 넣는 것이 일반적인 경험 법칙입니다. 서브클래싱이나 추상 메서드 구현으로 인해 필요에 따라 구현되지만 다시 한번 자주 다루지는 않습니다.

영역은 메서드 내에서 사용되어서는 안 됩니다.메소드를 그룹화하는 데 사용될 수 있지만 코드 독자가 미쳐버리지 않도록 극도의 주의를 기울여 처리해야 합니다.수정자에 의한 접기 방법에는 의미가 없습니다.그러나 때로는 접어서 가독성을 높일 수도 있습니다.예를 들어외부 라이브러리를 사용할 때 일부 문제를 해결하기 위해 사용하고 너무 자주 방문하고 싶지 않은 몇 가지 방법을 그룹화하는 것이 도움이 될 수 있습니다.그러나 코더는 항상 이 특정 예에서 적절한 클래스로 라이브러리를 래핑하는 것과 같은 솔루션을 찾아야 합니다.다른 모든 방법이 실패하면 가독성을 높이기 위해 접기를 사용하세요.

이것은 아무데도 연결되지 않는 어리석은 토론 중 하나 일뿐입니다.지역이 마음에 드시면 이용하세요.그렇지 않은 경우 해당 기능을 끄도록 편집기를 구성하세요.그곳에서는 모두가 행복합니다.

언어 고유의 코드 기능을 기반으로 지역 그룹화를 수동으로 유지 관리할 필요가 없다면 지역 접기는 괜찮을 것입니다.예를 들어, 컴파일러는 그것이 생성자라는 것을 이미 알고 있습니다.IDE의 코드 모델은 이미 그것이 생성자라는 것을 알고 있습니다.그러나 생성자가 함께 그룹화되어 있는 코드 보기를 보려면 어떤 이유로 생성자를 물리적으로 함께 배치한 다음 주위에 그룹을 배치하여 이러한 것들이 생성자라는 사실을 다시 설명해야 합니다.클래스/구조체/인터페이스를 분할하는 다른 방법에서도 마찬가지입니다.마음이 바뀌어서 공개/보호/비공개 항목을 먼저 그룹으로 분리한 다음 구성원 종류별로 그룹화하고 싶다면 어떻게 해야 합니까?

예를 들어 공용 속성을 표시하기 위해 영역을 사용하는 것은 코드 자체에서 이미 식별할 수 있는 항목에 아무것도 추가하지 않는 중복된 주석을 입력하는 것만큼 나쁩니다.

어쨌든, 해당 목적으로 영역을 사용할 필요가 없도록 Ora라는 무료 오픈 소스 Visual Studio 2008 IDE 추가 기능을 작성했습니다.자동으로 그룹화된 보기를 제공하므로 물리적 그룹화를 유지하거나 영역을 사용할 필요가 훨씬 줄어듭니다. 유용하다고 생각할 수도 있습니다.

일반적으로 C#에서 이벤트와 같은 코드를 처리할 때 실제로 이벤트 선언(EventArgs 클래스 대리자 선언 및 이벤트 선언)의 일부인 약 10줄의 코드가 있는 경우 주변에 영역을 배치한 다음 접습니다. 그런데 좀 더 읽기 쉬워졌습니다.

적절하게 사용하면 유용한 도구라고 생각합니다.많은 경우, 메서드와 열거형, 기타 자주 접히는 것들이 작은 블랙박스가 되어야 한다고 생각합니다.어떤 이유로 꼭 봐야 하는 경우를 제외하고는 내용은 중요하지 않으며 최대한 숨겨야 합니다.그러나 나는 개인 메소드, 주석 또는 내부 클래스를 절대 접지 않습니다.메소드와 열거형은 실제로 제가 접는 유일한 것입니다.

내 접근 방식은 영역을 사용하여 코드 블록을 생성자, 속성, 이벤트 등으로 구성하는 다른 접근 방식과 유사합니다.

Roland Weigelt의 블로그 항목에는 뛰어난 VS.NET 매크로 세트가 있습니다. #region에 대한 더 나은 키보드 지원 ...#endregion.나는 Ctrl+를 매핑하면서 수년 동안 이것을 사용해 왔습니다.현재 영역을 축소하려면 Ctrl++를 사용하여 확장하세요.모든 것을 접거나 펼치는 기본 VS.NET 기능보다 훨씬 더 잘 작동한다는 것을 알아보세요.

저는 개인적으로 항상 #Regions를 사용합니다.속성, 선언 등을 서로 분리된 상태로 유지하는 것이 도움이 된다는 것을 알았습니다.

이것도 아마 좋은 답변이 될 것입니다!

코딩 호러

편집하다:젠장, Pat이 나를 이겼어요!

나 자신은 #regions를 선호하지만, 옛 동료는 물건을 숨기는 것을 참을 수 없었습니다.7개의 #regions가 있는 페이지에서 작업한 후 그의 요점을 이해했습니다. 그 중 최소 3개는 자동 생성되었으며 동일한 이름을 가지고 있었지만 일반적으로 이러한 방법은 항목을 나누고 모든 것을 덜 유지하는 유용한 방법이라고 생각합니다. 어수선하다.

#region을 사용하여 코드를 구성하는 데에는 실제로 문제가 없습니다.개인적으로 저는 일반적으로 속성, 이벤트 핸들러, 공개/비공개 메서드와 같은 항목에 대해 서로 다른 영역을 설정합니다.

Eclipse는 이 중 일부를 Java(또는 플러그인이 있는 PHP)에서 자체적으로 수행합니다.기능 등을 접을 수 있습니다.나는 그것을 좋아하는 경향이 있습니다.어떤 기능이 무엇인지 알고 있고 그 기능을 수행하고 있지 않다면 그 기능을 볼 필요가 없습니다.

Emacs에는 접이식 마이너 모드가 있지만 가끔씩만 실행합니다.대부분 제가 교육을 덜 받았거나 코딩 방법에 덜 신경을 쓴 다른 물리학자로부터 물려받은 괴물을 연구할 때 그렇습니다.

영역 사용(또는 기타 코드 접기) ~해야 한다 코드 냄새(또는 숨기기) 또는 사람들이 "쉽게" 볼 수 없도록 코드를 숨기는 다른 아이디어와는 아무런 관련이 없습니다.

영역 및 코드 접기는 실제로 현재 작업 중인 작업 주위에 불필요한 "노이즈"의 양을 최소화하기 위해 축소/접기/숨길 수 있는 코드 섹션을 쉽게 그룹화하는 방법을 제공하는 것입니다.올바르게 설정하면(포함된 메서드 이름과 같이 실제로 영역에 유용한 이름을 지정한다는 의미) 현재 편집 중인 함수를 제외한 모든 항목을 축소하고 실제로 다른 함수를 볼 필요 없이 일정 수준의 컨텍스트를 계속 유지할 수 있습니다. 코드 라인.

아마도 이러한 아이디어에 대한 몇 가지 모범 사례 유형 지침이 있어야 하지만 저는 지역을 광범위하게 사용하여 코드 파일에 표준 구조를 제공합니다(그룹 이벤트, 클래스 전체 필드, 개인 속성/메서드, 공용 속성/메서드).각 메서드 또는 속성에는 영역 이름도 있으며, 여기서 영역 이름은 메서드/속성 이름입니다.오버로드된 메서드가 여러 개 있는 경우 영역 이름은 전체 서명이고 전체 그룹은 함수 이름인 영역에 래핑됩니다.

저는 개인적으로 지역을 싫어합니다.제 생각에는 지역에 있어야 하는 유일한 코드는 생성된 코드입니다.파일을 열 때 항상 Ctrl+M+O로 시작합니다.이는 메서드 수준으로 접힙니다.지역이 있으면 지역 이름만 표시됩니다.

체크인하기 전에 메서드/필드를 논리적으로 그룹화하여 Ctrl+M+O 후에도 괜찮아 보이도록 합니다.지역이 필요한 경우 수업 시간에 줄이 많아야 합니다.나는 또한 이것이 매우 흔한 일이라는 것을 알았습니다.

지역 ThisLooksLikeWellOrganizedCodeBecauseIUseRegions

// 전체 쓰레기, 여기에는 구조가 없습니다.

지역 끝

열거

속성

.ctors

행동 양식

이벤트 핸들러

이것이 제가 지역을 사용하는 전부입니다.메소드 내부에서 사용할 수 있다는 것을 전혀 몰랐습니다.

끔찍한 생각인 것 같네요 :)

그만큼 코딩 호러 실제 기사를 통해 이것에 대해서도 생각하게되었습니다.

일반적으로 대규모 클래스에서는 멤버 변수, 상수 및 속성 주위에 영역을 배치하여 스크롤해야 하는 텍스트의 양을 줄이고 다른 모든 항목은 영역 외부에 둡니다.양식에서는 일반적으로 항목을 "멤버 변수, 상수 및 속성", 양식 함수 및 이벤트 처리기로 그룹화합니다.다시 한번 말씀드리지만 이는 일부 이벤트 핸들러를 검토할 때 많은 텍스트를 스크롤할 필요가 없도록 하기 위한 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top