나는 C #에 대한 AvSol 코딩 지침 을 살펴 보았고 거의 모든 것에 동의하지만 다른 특정 규칙에 대해 어떻게 생각하는지 궁금합니다.
AV1500
방법이 7 개 진술을 초과해서는 안됩니다. 7 개 이상의 진술이 필요한 방법이 너무 많은 일을하거나 너무 많은 책임이 있습니다. 또한 인간의 마음이 정확한 진술을 분석하여 코드가 수행하는 작업을 이해해야합니다. 스스로 설명하는 이름으로 작고 집중된 여러 가지 방법으로 분류하십시오.
대부분이 규칙을 따르십니까? 가독성을 크게 높이는 것 외에 새로운 메소드를 작성하는 것 (코드가 여전히 DRY ) 에서 절약 할 것이 거의 없습니까? 그리고 당신의 숫자는 여전히 7만큼 낮습니까? 나는 10쪽으로 향하는 경향이 있습니다.
나는이 규칙을 모든 곳에서 위반한다고 말하는 것이 아니라 반대로, 내 방법은 95 % 작고 집중적이지만이 규칙을 위반해서는 안된다는 말은 실제로 나를 날려 버렸다.
나는 모든 사람들이이 규칙을 위반하지 않는다고 생각하는 것을 정말로 알고 싶다. (코딩 표준에서 ‘1’이다. 그러나 그렇지 않은 코드베이스를 찾는 데 문제가 있다고 생각합니다.
답변
이것은 나에게 “표준 냄새”입니다. 특정 제한이있는 코딩 표준을 볼 때마다 걱정합니다. 거의 항상 메소드가 표준 허용보다 커야하는 경우가 발생합니다 (라인 길이 / 카운트 수, 변수 수, 종료점 수 등). 표준은 지침과 비슷해야하며, 올바른 판단을 내리기에 충분한 여유가 있어야합니다. 틀리지 말고 표준을 갖추는 것이 좋지만 “프록시를 통한 미세 관리”가되어서는 안됩니다.
답변
일반적으로 물건을 작은 방법으로 나누는 것이 좋습니다. 그러나 중요한 것은 의미가있는 부분을 나누는 것입니다.
분할이 타당하지 않으면 분할하지 마십시오. 일부 절차 또는 GUI 코드의 경우가 종종 있습니다.
Steve McConnell 은 Code Complete 에서 짧은 방법을 사용할 때 항상 생산성이 높지는 않다고 말했습니다 . 의미가 없을 때 분할하면 코드에 복잡성을 추가하여 아무런 이점이 없습니다.
항상 지침과 마찬가지로 제약 조건이 존재하는 이유를 기억하는 것이 좋으므로 적용되지 않을 때 배울 수 있습니다. 대부분의 코드에서 메서드가 짧거나 DRY 또는 문제 분리에 문제가있을 수 있습니다. 그러나 그렇지 않다면 괜찮습니다.
답변
경험 법칙으로 간주해야합니다.
“텍스트 열 80 (100,120) 개 이하”, “방법 당 하나의 종료점”, “2 단계 이하의 중첩”과 같은 것은 코드 냄새 표시기의 임계 값이라고 부르는 것입니다. 때때로 위반하는 경우 코드가 잘못되었다는 의미는 아닙니다. 자신이 지속적으로 위반하는 것을 발견하면 코드에서 무언가 냄새가 나고 잠시 멈추고 접근 방식을 다시 생각할 수 있습니다.
나에게 가장 중요한 기준은 “이 코드를 이해할 수 있는가?”, “반복적인가?”, “논리적 장소에서 나뉘어 집니까?”, “느슨하게 결합되어 있습니까?”입니다. 몇 가지가 더 있지만, 저는 도널드 크 누스의 조언을 기억함으로써 기본적인 아이디어를 요약 할 수 있다고 생각합니다. “프로그램은 인간이 읽고 컴퓨터를 실행할 수 있도록 의도 된 것입니다.”
답변
필자는 실제로 메서드의 문 수를 계산하는 데 시간을 들이지 않았지만 하나의 명확한 목적을 명확하게 수행하는 메서드를 작성하려고 노력합니다. 코드가 깨끗하고 읽기 쉽고 DRY 및 단일 책임 원칙을 따르는 한, 아마도 작업을 수행 한 것입니다. 7 문장 제한을 강제하기 위해 메소드를 임의로 분리하면 코드를 읽기 어렵게 만들 수 있다고 생각합니다.
답변
대략적인
이런 종류의 규칙은 문자 그대로 받아 들여서는 안됩니다. 그들은 ” 방법이 짧아야한다 ” 고 말할 수있었습니다 . 그러나 일부 사람들은 “1 페이지 미만”으로 해석하고 다른 사람들은 “최대 2 줄”로 해석했을 것입니다.
나는 그들이 당신에게 대략적인 아이디어를주기 위해 “7 개의 진술”을했다고 가정 할 것입니다. 한 번에 9가 필요하다면 땀을 흘리지 마십시오. 하지만 20을 쳤다면이 규칙에 맞는 구장에 있지 않다는 것을 알게 될 것입니다.
답변
7은 의미가 전혀없는 완전 임의의 숫자입니다.
순환 복잡도 는 진술의 수보다 더 큰 문제입니다. 단일 방법으로 100 개의 문장을 가진 코드를 보았지만 (끔찍하다고 생각했지만) 순환 복잡성이 1이고 실제로는 한 가지 일만했습니다. 많은 단계가있었습니다. 우리는 더 작은 메소드로 나누는 것에 대해 논의했지만, 이러한 메소드는이 하나의 메소드에 의해서만 호출됩니다.
이는 극단적 인 경우이지만 코드를 DRY로 유지하고 순환 복잡성을 낮추어야합니다. 메소드의 행 수보다 더 중요합니다.
스위치 / 케이스 문을 예로 들어 보자. 7 개 이상의 가능한 값이있는 경우 평가를 여러 방법으로 나누어야합니까? 물론, 그것은 어리석은 일입니다.
7 이하의 문장 수를 유지하기 위해 인위적으로 코드를 더 많은 방법으로 나누면 코드가 악화됩니다.
지침은 다음과 같습니다 각 방법은 한 가지 일을하고 코드를 건조하게 유지해야합니다.
답변
글쎄, 그것은 조금 다릅니다. 데이터베이스에 액세스하는 많은 코드를 작성합니다. 예외 처리를위한 보일러 플레이트 코드는 많은 경우에 7 개 이상의 진술입니다. 최선의 지침은 함수가 하나의 목적을 가지고 있는지 확인하는 것입니다.