코딩 가이드 라인 : 메소드는 7 개 이상의 명령문을 포함하지 않아야합니까?


78

나는 C #에 대한 AvSol 코딩 지침살펴 보았고 거의 모든 것에 동의하지만 다른 특정 규칙에 대해 어떻게 생각하는지 궁금합니다.

AV1500

방법이 7 개 진술을 초과해서는 안됩니다. 7 개 이상의 진술이 필요한 방법이 너무 많은 일을하거나 너무 많은 책임이 있습니다. 또한 인간의 마음이 정확한 진술을 분석하여 코드가 수행하는 작업을 이해해야합니다. 스스로 설명하는 이름으로 작고 집중된 여러 가지 방법으로 분류하십시오.

대부분이 규칙을 따르십니까? 가독성을 크게 높이는 것 외에 새로운 메소드를 작성하는 것 (코드가 여전히 DRY ) 에서 절약 할 것이 거의 없습니까? 그리고 당신의 숫자는 여전히 7만큼 낮습니까? 나는 10쪽으로 향하는 경향이 있습니다.

나는이 규칙을 모든 곳에서 위반한다고 말하는 것이 아니라 반대로, 내 방법은 95 % 작고 집중적이지만이 규칙을 위반해서는 안된다는 말은 실제로 나를 날려 버렸다.

나는 모든 사람들이이 규칙을 위반하지 않는다고 생각하는 것을 정말로 알고 싶다. (코딩 표준에서 '1'이다. 그러나 그렇지 않은 코드베이스를 찾는 데 문제가 있다고 생각합니다.


48
그들은 case한 마디로 진술 을 계산 switch합니까? 어쨌든 그것은 바보 같은 쓸모없는 요구에 지나지 않습니다. 그것을 쓴 사람들은 프로그래밍에 대해 아무것도 모른다.
SK-logic

86
코딩 표준에서 '1'이어야하는 유일한 규칙은 "모든 소금 지침을 가진 코딩 지침을 취해야합니다"라는 규칙이어야합니다.
Mike Nakis

6
@ SK-logic 1027도 나쁘지 않습니다. 빈 문자열을 null 문자열과 동일하게 취급해야하는 경우 누락 된 데이터를 처리해야하는 코드를 작성하는 것이 재미 있어야합니다.
quant_dev

25
이 가이드 라인을 읽을 때 다음과 같은 코드베이스로 가득 차있을 것입니다. void DoSomething () {DoSomethingFirstSevenLines (); DoSomethingSecondSevenLines (); DoSomethingThirdSevenLines (); 기타; }
예인선

12
.NET Framework의 대부분을 반영하는 시도 미만 7 문 ... 얼마나 많은 방법을 참조
데이비드 Boike을

답변:


195

이것은 나에게 "표준 냄새"입니다. 특정 제한이있는 코딩 표준을 볼 때마다 걱정합니다. 거의 항상 메소드가 표준 허용보다 커야하는 경우가 발생합니다 (라인 길이 / 카운트 수, 변수 수, 종료점 수 등). 표준은 지침과 비슷해야하며, 올바른 판단을 내리기에 충분한 여유가 있어야합니다. 틀리지 말고 표준을 갖추는 것이 좋지만 "프록시를 통한 미세 관리"가되어서는 안됩니다.


25
"프록시에 의한 미세 관리"+1 누군가가 "7 더하기 또는 빼기 2"규칙 ( en.wikipedia.org/wiki/… ) 에 대해 읽고 코드 편집기와 같은 장기 저장소와 혼동되는 단기 사실 보존을 혼동한다고 생각합니다.
푹신한

25
현명하게 생각 된 표준은 코드에서 마법의 숫자를 금지합니다. 코딩 표준도 그 표준을 준수한다고 생각할 것입니다. 숫자 7은 확실히 "매직"품질입니다.
Adam Crossland

2
문서 제목이 " GuidlinesC # 3.0 및 4.0 코딩"이 아닌 경우 답변이 더 의미가 있습니다.
Andy

+1 내 생각에 코딩 표준을 따라야하는 유일한 이유는 절대적으로 임의의 숫자를 따르는 것이 아니라 버전 관리에서 불필요한 병합 문제 (예 : 팀에서 작업 할 때 관련된 문제)가 발생하지 않도록하는 것입니다. 일반적으로 파일이 짧고 구성 요소가 많을수록 코드 변경 사항을 병합 할 때 문제가 발생할 가능성이 줄어 듭니다.
Spoike

3
이 문서를 다운로드하여 살펴보기 시작했습니다. 1.6에서는 다음과 같이 기술하고있다 : "문서는 프로젝트가이 가이드 라인을 준수해야한다고 명시하지 않으며, 어떤 가이드 라인이 다른 가이드 라인보다 더 중요하다고 말하지는 않습니다. "의심이 생길 경우 컨설턴트는 누구이며, 소스 코드에는 어떤 레이아웃을 사용해야합니까?" 1은 "건너 뛰지 말아야하고 모든 솔루션에 적용 할 수 있어야하는 지침"을 의미하지만이를 수정하도록 선택할 수 있습니다.
chrish

83

일반적으로 물건을 작은 방법으로 나누는 것이 좋습니다. 그러나 중요한 것은 의미가있는 부분을 나누는 것입니다.

분할이 타당하지 않으면 분할하지 마십시오. 일부 절차 또는 GUI 코드의 경우가 종종 있습니다.

Steve McConnellCode Complete 에서 짧은 방법을 사용할 때 항상 생산성이 높지는 않다고 말했습니다 . 의미가 없을 때 분할하면 코드에 복잡성을 추가하여 아무런 이점이 없습니다.

항상 지침과 마찬가지로 제약 조건이 존재하는 이유를 기억하는 것이 좋으므로 적용되지 않을 때 배울 수 있습니다. 대부분의 코드에서 메서드가 짧거나 DRY 또는 문제 분리에 문제가있을 수 있습니다. 그러나 그렇지 않다면 괜찮습니다.


1
좋은 대답입니다. 마지막 두 줄은 특히 요점을 몰아냅니다.
Xonatron

6
엄지 손가락의 중요한 규칙은 하위 방법이 직교인지 확인하는 것입니다. 그들이 독립적이라면, 어떤 순서로든 호출 될 수 있고 클래스를 불변으로 존중할 수 있다면 그것들을 분리하는 것이 좋습니다. 메소드가 밀접하게 결합되어 클래스 불변을 중단하거나 특정 순서로 호출 해야하는 경우 함께 유지하는 것이 좋습니다.
hugomg

4
코드 완성에는 좋은 것들이 가득합니다. 모든 프로그래머는 매일 점심을 먹어야합니다.
deadalnix

29

경험 법칙으로 간주해야합니다.

"텍스트 열 80 (100,120) 개 이하", "방법 당 하나의 종료점", "2 단계 이하의 중첩"과 같은 것은 코드 냄새 표시기의 임계 값이라고 부르는 것입니다. 때때로 위반하는 경우 코드가 잘못되었다는 의미는 아닙니다. 자신이 지속적으로 위반하는 것을 발견하면 코드에서 무언가 냄새가 나고 잠시 멈추고 접근 방식을 다시 생각할 수 있습니다.

나에게 가장 중요한 기준은 "이 코드를 이해할 수 있는가?", "반복적인가?", "논리적 장소에서 나뉘어 집니까?", "느슨하게 결합되어 있습니까?"입니다. 몇 가지가 더 있지만, 저는 도널드 크 누스의 조언을 기억함으로써 기본적인 아이디어를 요약 할 수 있다고 생각합니다. "프로그램은 인간이 읽고 컴퓨터를 실행할 수 있도록 의도 된 것입니다."


7
"80/100/120"열 제한은 코드를 읽을 수 있도록하기위한 것입니다. 대부분의 터미널은 80 열로 열리므로 코드를 읽을 때마다 모든 독자가 터미널의 크기를 조정하는 것보다 작성자를 80 열로 줄이려는 노력이 적습니다. 다른 제한과 달리 N 열 제한은 코드의 의미에 영향을 미치지 않으며 순전히 문체 규칙입니다. "4 개의 공백 탭 사용"또는 "자신의 라인에 기능을위한 여는 중괄호 입력"과 같은 범주에서
Dietrich Epp

4
물론 그것은 의미 론적 측면보다 미학적 측면이다. 그러나 그것이 나의 마지막 문장이 적용되는 곳입니다. 행을 분할 할 "좋은"위치가없는 80 열 규칙을 초과하는 Java 문을 찾는 것은 드문 일이 아닙니다. 이것은 코드의 가독성과 이해에 영향을줍니다. 또한 Demeter
seggy

7
21 세기에는 IDE에 "dynamic word wrap"이라는 기능이 있습니다.
György Andrasek

9
@ GyörgyAndrasek : 그러나 모든 사람이 항상 IDE를 사용하는 것은 아닙니다. 우리는 GitHub의 코드를 less, in vimemacs; 자동 포장은 최선의 방법으로 보입니다. 코딩 표준은 귀하의 이익을위한 것이 아니라 팀에서 일하는 사람들의 이익을위한 것입니다.
Dietrich Epp

2
@DietrichEpp 개인적으로 나는 항상 80 열에 싸인 코드를 읽는 데 어려움을 겪고 있습니다. 최근에는 표준 Eclipse 포맷터가 사용 된 Java 프로젝트를 작업해야했습니다. 그리고 방법 내에서 두 줄 또는 세 줄을 넘은 줄을 추적하는 것은 매우 어려웠습니다 (나는 다른 포맷터 설정도 비난합니다). 결론은 80이 약간 구식이라고 생각합니다. 개인적으로 120을 사용하고, 편집자에게 강제로 설정하고, 120 열 너비의 콘솔이 있고 Github은 실제로 125 개의 열을 표시합니다. 그리고 나는 그것이 훨씬 더 읽기 쉽다고 생각합니다.
찌를

18

필자는 실제로 메서드의 문 수를 계산하는 데 시간을 들이지 않았지만 하나의 명확한 목적을 명확하게 수행하는 메서드를 작성하려고 노력합니다. 코드가 깨끗하고 읽기 쉽고 DRY단일 책임 원칙을 따르는 한, 아마도 작업을 수행 한 것입니다. 7 문장 제한을 강제하기 위해 메소드를 임의로 분리하면 코드를 읽기 어렵게 만들 수 있다고 생각합니다.


1
가독성 +1 방법이 20 줄, 30 줄, 심지어 50 줄이면 문제가되지 않습니다. DRY와 SRP가 당신의 목표라면, 메소드가 더 긴쪽에있는 것처럼 보일지라도 중요하지 않습니다 ... 자연스럽게 될 것입니다.
S.Robins 2019

11

대략적인

이런 종류의 규칙은 문자 그대로 받아 들여서는 안됩니다. 그들은 " 방법이 짧아야한다 " 고 말할 수있었습니다 . 그러나 일부 사람들은 "1 페이지 미만"으로 해석하고 다른 사람들은 "최대 2 줄"로 해석했을 것입니다.

나는 그들이 당신에게 대략적인 아이디어를주기 위해 "7 개의 진술"을했다고 가정 할 것입니다. 한 번에 9가 필요하다면 땀을 흘리지 마십시오. 하지만 20을 쳤다면이 규칙에 맞는 구장에 있지 않다는 것을 알게 될 것입니다.


그것은 꽤 명백한 근사치입니다. "건너 뛰지 말아야하고 모든 상황에 적용 할 수 있어야하는 지침"에 표시되어 있습니다.
brian

1
@brian-아마도 가이드 라인 작가들이 우연히 "거의"라는 단어를 생략했을 수도 있고 미친 독재자 유형일 수도 있습니다. 요점은 OP가 이것을 야구장 번호로 가져 가야한다는 것입니다. 컴파일러 나 인터프리터가 시행하지 않는 규칙은 단지 제안 일뿐입니다.
Nathan Long

"컴파일러 나 인터프리터가 강제하지 않는 규칙은 단지 제안 일뿐입니다."반드시 그런 것은 아닙니다. 나는 그의 사용자 정의 resharper 또는 fxcop 규칙을 보지 않고 실제로이 특정 규칙을 시행하는지 여부를 보지 만 모든 스타일 지침에 대해 검증 해야하는 회사가 있습니다. 회사에서 엄격한 Microsoft 코딩 지침을 통과 할 수있는 코드를 작성하도록하는 사람들을 만났습니다.
brian

나는 그것이 근사치이며 소금 한 덩어리로 가져 가야한다는 데 동의합니다. 코드 표준 단락이 임의의 숫자를 가져 오면 필연적으로 혼란을 초래할 것입니다. 대부분의 경우 표준은 맥락에서 벗어나고 "사람"은 그 임의적 근사를 교리로 따릅니다.
Spoike

10

7은 의미가 전혀없는 완전 임의의 숫자입니다.

순환 복잡도 는 진술의 수보다 더 큰 문제입니다. 단일 방법으로 100 개의 문장을 가진 코드를 보았지만 (끔찍하다고 생각했지만) 순환 복잡성이 1이고 실제로는 한 가지 일만했습니다. 많은 단계가있었습니다. 우리는 더 작은 메소드로 나누는 것에 대해 논의했지만, 이러한 메소드는이 하나의 메소드에 의해서만 호출됩니다.

이는 극단적 인 경우이지만 코드를 DRY로 유지하고 순환 복잡성을 낮추어야합니다. 메소드의 행 수보다 더 중요합니다.

스위치 / 케이스 문을 예로 들어 보자. 7 개 이상의 가능한 값이있는 경우 평가를 여러 방법으로 나누어야합니까? 물론, 그것은 어리석은 일입니다.

7 이하의 문장 수를 유지하기 위해 인위적으로 코드를 더 많은 방법으로 나누면 코드가 악화됩니다.

지침은 다음과 같습니다 각 방법은 한 가지 일을하고 코드를 건조하게 유지해야합니다.


1
+1 : 임의 한도는 임의로 유용합니다. 메소드는 단일 추상화 레벨에서 단일 코 히어 런트 연산을 포함해야합니다. 그러한 원자 단위를 깨 뜨리면 코드가 더 복잡해져 코드를 이해하기가 더 어려워집니다.
Allon Guralnek

드라이가 과대 평가되었습니다. 종종 그것은 밀접하게 결합되어서는 안되는 무언가의 두 가지 측면을 밀접하게 결합하는 것을 의미합니다.
Brad Thomas

4

글쎄, 그것은 조금 다릅니다. 데이터베이스에 액세스하는 많은 코드를 작성합니다. 예외 처리를위한 보일러 플레이트 코드는 많은 경우에 7 개 이상의 진술입니다. 최선의 지침은 함수가 하나의 목적을 가지고 있는지 확인하는 것입니다.


8
상용구 코드를 고유 한 방법으로 추상화 할 수 없습니까?
erjiang

나는 이것이 Java가 아닌 C #임을 게시 한 후이 종류의 것을 생각하고 있음을 알았습니다. stackoverflow.com/questions/321418/…
Jaydee

@erjang : 할 수 있습니다. 각 쿼리를 익명 클래스로 래핑해야하지만 여전히 가치가 있기 때문에 Java에서는 매우 추악합니다. C #에서는 그렇게 추한 것은 아니며 확실히 가치가 있습니다.
kevin cline

개인적으로, 몇 줄의 staight line 코드가 더 읽기 쉽다는 것을 알았습니다. 그러나 아마도 그것은 단지 나일 것입니다.
Jaydee 2012

@Jaydee 연결된 질문은 일반적이지만 이상한 연습을 보여줍니다 : 예외 랩핑 및 로깅. 다음 단계에서 똑같이 할 수 있습니다 ...이 방법으로 단일 예외가 로그에 여러 번 나타납니다. 메소드 던지기를 선언하고 3 줄을 저장하는 것이 좋습니다. 모두 닫는 도우미 메서드 쓰기 psrs다른 하나를 저장합니다. 또는 List<Row> readDb(String sql, Object... args)전체 작업을 수행 하는 메서드 를 작성하십시오 (메모리에 맞는 결과 집합에만 작동하지만 너무 많은 데이터를 가져 오는 것은 일반적으로 작업이 DB에서 수행되어야 함을 의미합니다).
maaartinus

4

모든 것이 절충입니다. 제안 된 접근 방식의 문제점-여러 방법과 클래스로 리팩토링하여 각 방법이 짧아짐-다른 이유로도 극단적 인 경우 읽을 수없는 코드로 이어진다는 것입니다.

foo()7 가지 일을 하는 방법 을 상상해보십시오 . 7 가지가 너무 많다고 주장 할 수 있습니다. 아마도 많은 경우에 당신이 옳을 것입니다. 반면에이 7 가지 사항은 밀접한 관련이있을 수 있습니다. 논리는 매끄럽게 흐르고 산문처럼 읽을 수 있습니다. 실제로 필요할 때 이해하는 데 어려움이 없을 수 있습니다. 더 나쁜 결과는 7 가지를 큰 소스 트리에 분산 시켜서 foo()7 가지 다른 장소를 보지 않고 그 기능이 무엇인지 전혀 모르는 것입니다.

많은 사람들이 머리에 이와 같은 규칙을 얻습니다. 결과는 OO 스파게티로 생각됩니다. 모든 것이 깔끔하고, 작은 방법 또는 클래스로 박스 화되어 있으며, 각 장소에서 원자 적으로 작은 마이크로 트랜잭션이 발생합니다. 그러나 그러한 코드 기반을 새롭게하고 그것이 무엇을하고 있는지 아는 것은 불가능합니다. 당신은 길을 잃게됩니다.


4

나쁜 지침이 아닙니다. 나는 그룹화되고 충분히 관련되어있는 한 메소드와 클래스를 나누는 것을 결코 후회하지 않았습니다.

요령은 그것을 수직으로 나누지 않는 것입니다 (한 지점에서 방법을 집어 내고 새로운 방법을 시작하십시오). 단위 테스트와 마찬가지로 트릭은 처음부터 이러한 규칙을 염두에두고 실제로 메서드를 더 잘 설계하고 메서드 중 3 개 또는 4 개의 문을 다른 메서드로 전달하는 것입니다. 코드 중간에있는 3 개 또는 4 개의 진술.

이러한 종류의 분할은 임의적이고 한 번만 사용하더라도 나중에 새로운 코드의 명확성으로 인해 더 나은 리팩토링으로 이어질 수 있습니다. 이는 작은 클래스에서도 마찬가지입니다.

단위 테스트처럼 생각하십시오. 사실 후에 단위 테스트를 추가하려고하면 어렵고 때로는 불가능한 것처럼 보이지만 처음부터 디자인하면 실제로 모든 코드가 향상됩니다.

요약? "7 개 미만의 문 사용"의 디자인 냄새를 "7 개 이상의 문을 사용한"코드 냄새와 비교하면 코드 냄새가 제거됩니다.


4

와! 나는 당신의 방법이 매우 작아야한다고 대략적으로 말하는 간단한 지침에 대해 그렇게 강렬한 토론을 기대하지 않았습니다. 가이드 라인을 명시 적으로 표현하려는 개발자는 항상 개발자이기 때문에 7이 좋은 선택입니다.

일부는 이미 문서의 시작 부분에 고지 사항을 인용했습니다. 그러나이 문서는 더 나은 코드를 작성하고 더 나은 시스템을 설계하는 데 도움이되는 지침 모음을 나타냅니다. 가이드 라인이 레벨 1로 표시되어 있어도 규칙이되어야한다고 언급 한 적이 없습니다. 이러한 레벨은이 문서를 한동안 사용해온 많은 사람들의 단순한 의견입니다.

나는 또한 전문가라고 주장한 적이 없다. 그러나 나는 약 4 년의 C ++ 경험과 11 년의 C # 경험으로 15 년 동안이 직업에 종사해 왔습니다. 원래 Industrial Strength C ++를 기반으로했지만 그 이후로 커뮤니티의 의견을 받아 정제했습니다.

어쨌든, 내가 높이려고 한 것은 당신이 계속 스스로 생각해야한다는 것입니다. 7 가지 진술 지침이 유용하지 않다고 생각한다면, 그것을 더 길게 만드는 것보다. 심지어 그 지침을 때때로 위반하는 경우도 있습니다. 나는 단지 그것을 성실하게 위반하고 그 결과를 받아들입니다.


3
당신을 반기 게하고, 나는 당신이 합리적인 논쟁을한다고 생각합니다. "저는 항상 가이드 라인을 명시 적으로 밝히기를 원하는 개발자입니다"라는 이론적 근거에 동의하지 않습니다. 가이드 라인을 명시 적으로 만드는 것이 잘못되지 않는 한 좋습니다 : 이제는 더 이상 가이드 라인이 아니며, 임의의 규칙입니다. 당신이 목격했듯이, 임의의 숫자를 소개하는 것은 격추되고 정당화 될 수있는 특정한 방법입니다.
Konrad Rudolph

3

첫째, 규칙이 아니라 지침입니다. 이를 지침이라고하므로 그렇게 취급하십시오. 이것은 (항상처럼) 자신의 판단이 필요하다는 것을 의미합니다

그 외에도이 제약 조건을 준수하지 않는 좋은 코드의 예를 많이 생각할 수 있습니다. 비록 단지 지침 일지라도, 그것은 좋지 않은 것입니다.


2

위의 진술에 동의합니다. 이것은 단지 지침 일 뿐이며 완벽한 세상에서 모든 것이 대상이되고 모든 프로그램에서 재사용되며 세상은 아름다운 곳이 될 것입니다. 항상 사실이 아니며 때로는 많은 오버 헤드 나 리소스 낭비로 이어질 수도 있습니다. 당신도 그걸 명심해야합니다.


6
"위의 진술에 동의합니다"스택 교환 사이트에서 이러한 종류의 문장을 피하십시오. 답변이 게시 된 순서는 반드시 표시되는 순서는 아닙니다.
luiscubal

너무 늦을 때까지 생각하지 않았습니다. 그러나 나는 여전히 내 뇌 방귀를 지적하여 당신을 +1 할 것입니다.
Falcon165o

2

혼합물에 예외 처리를 추가 할 때 꽤 어리 석습니다.

"try, catch, finally"후에는 메소드 당 4 개의 명령문이 남습니다!

또한 개별 필드에서 모든 개별 유효성 검증을 처리하더라도 20 개의 필드 유효성 검증 메소드를 호출하더라도 20 개의 필드 양식에 대해 "validateForm"메소드를 고려하십시오. 이 지침에 따르면 "validateTopOfScreen", "validateMiddleOfScreen"및 "validateBottomOfScreen"과 같은 무의미한 분할로 끝납니다.


C #에서는 try/ catch/ finally문이 아니라고 말하는 것이 안전하다고 생각합니다 . Ecma-334 § 12.3.3.15 및 주변 섹션을 참조하십시오. (약칭) " try-catch-finally 형식의 진술 : try -block catch (...) catch-block-n 최종적 으로 차단 "
CVn

글쎄, 내가 전에 말했듯이, 당신이 계속해서 결정해야한다는 결정. 그러나 특정 예제는 객체 지향 디자인을 올바르게 수행하지 않는 예제 일 수 있습니다. 화면을 유효성 검사 자체를 수행하는 여러 컨트롤로 분할 할 수 있습니다.
Dennis Doomen 2012

@Dennis-사실 HTML 양식을 너무 오랫동안 사용하고 있습니다!
제임스 앤더슨

@ 제임스 그리고 이것이이 특정 지침을위한 것입니다. 대안적이고 잠재적으로 더 나은 솔루션을 생각하게 만듭니다.
Dennis Doomen

2

문제는 "지침"과 "규칙"을 혼동시키는 것입니다. 규칙은 준수되어야합니다. 가이드 라인은 수행중인 작업과 실제로 더 나은 방식으로 수행 할 수 있는지 고려하도록하는 조언입니다.

평균적으로, 대부분의 프로그래밍은 아마도 가이드 라인을 따라 개선 될 것입니다. 그러나 가이드 라인을 따르게되면 해결하려는 것보다 더 많은 문제가 발생하는 경우가 항상있을 것입니다. 이것이 규칙으로 제시되는 것이 아니라 지침입니다.

이전의 답변자는 가이드 라인을 작성한 사람들이 결코 독단적으로 적용되도록 의도하지 않았으며 문서에 그 영향에 대한 진술을 포함시키지 않았다.


0

위의 의견에 동의합니다. 나를 위해 7은 임의적이며 루비가있는 일부 언어에서는 유용 할 수 있지만 C #, Java, C ++와 같은 언어에서는이 "7 줄"규칙을 의심합니다. 현재 응용 프로그램에 22 개의 텍스트 필드가 있으며 서버 측 유효성 검사를 수행합니다. 이 메소드는 validateInput ()이며 checkEmailFormat ()과 같은 복잡한 것을 검증하지 않으면 기본 설정은 하나의 메소드 자체에서 모든 필드의 유효성을 검사합니다. 따라서 기본적으로 validateInput 메소드 코드는 복잡한 유효성 검사를 가끔 호출하는 108 줄입니다.

이제 각 필드의 유효성을 검사하기 위해 25 개의 메소드를 호출했다고 가정하십시오. 새로운 개발자가 들어 오면 25 가지 방법을 건너 뛰기 위해 주요 방법으로 들어가고 나가야합니다. 그는 큰 프로젝트에서 길을 잃어야한다.

내 코드를 명확하게하기 위해 실제로하는 것은 기본적 으로이 4 줄이 전하는 일을 말하는 명확한 주석을 제공하는 것입니다.

validateInput (UserObj 사용자) {

// 이름 확인 ....... ......

// 성을 확인 ...... ......

// 이메일 확인 ..... // 이메일 형식을 확인하기에는 너무 복잡하다 정기적 expresion checkEmailFormat (); .... .....

등등.. }


1
제임스 앤더슨의 질문에 대한 나의 답변도 참조하십시오. 귀하의 특별한 경우에, 그 유효성 검사 방법이 여러 원칙과 지침을 동시에 위반하지 않는지 궁금합니다.
Dennis Doomen

0

나쁜 규칙. 예외 처리, 데이터베이스 필드 설정, 유효성 검사를위한 코드를 사용하여 대부분의 메소드를 어떻게 7 개의 명령문으로 작성할 수 있습니까? 인라인 람다 함수를 절대 사용해서는 안됩니까?

코드 라인은 임의의 복잡성입니다. 확장 방법을 사용하면 다음과 같은 코드를 만들 수 있습니다

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

단일 방법으로 너무 많은 일을하는 좋은 예입니다. 거의 모든 반론에서 사람들은 단일 책임 원칙 (방법의 맥락에서)을 위반하고 있습니다.
Dennis Doomen

-1

모든 주니어 프로그래머는이 원칙을 준수해야합니다. 이로 인해 점점 더 많은 라인 코드를 추가하는 대신 바쁜 바의 구조에 대해 생각하게됩니다.

나는 현재 많은 if 문과 함께 550 줄의 코드 메소드를 찾고 있으며 계속해서 리턴합니다. 쓰레기 야 프로그래머는 자신이하고있는 일에 대해서만 생각해야했습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.