이상적인 방법 길이는 얼마입니까? [닫은]

객체 지향 프로그래밍에서는 물론 메소드의 최대 길이에 대한 정확한 규칙은 없지만 여전히이 두 따옴표가 서로 약간 모순되는 것을 알았으므로 귀하의 생각을 듣고 싶습니다.

에서 클린 코드 : 애자일 소프트웨어 장인의 수첩 , 로버트 마틴은 말합니다 :

함수의 첫 번째 규칙은 작아야한다는 것입니다. 함수의 두 번째 규칙은 그보다 작아야한다는 것입니다. 기능은 100 줄을 넘지 않아야합니다. 기능은 거의 20 줄이되지 않아야합니다.

그는 Kent Beck에서 본 Java 코드의 예를 보여줍니다.

그의 프로그램의 모든 기능은 단지 2, 3, 4 줄 길이였습니다. 각각은 분명했다. 각각 이야기를했습니다. 그리고 각각 당신을 설득력있는 순서로 다음으로 이끌었습니다. 기능이 얼마나 짧아야하는지!

이 큰 소리를하지만, 다른 한편으로는,에 전체 코드 , 스티브 맥코넬은 매우 다른 것을 말한다 :

이 루틴은 유기적으로 최대 100-200 라인까지 자랄 수 있어야하며, 수십 년의 증거에 따르면 그러한 길이의 루틴은 더 이상 오류가 발생하지 않는 것이 루틴이 짧을 것입니다.

그리고 그는 65 줄 이상의 루틴을 개발하는 것이 더 저렴하다고 연구에 대한 언급을한다.

따라서 문제에 대한 의견이 다양하지만 기능적인 모범 사례가 있습니까?

Java 또는 C #으로 코딩 할 때 일반적으로 함수는 짧아야합니다 (5-15 줄). 여러 가지 이유로 좋은 크기입니다.

• 스크롤하지 않고도 화면에 쉽게 맞습니다.
• 머리에 붙일 수있는 개념적 크기에 관한 것입니다.
• 자체적으로 기능을 필요로 할 정도로 의미가 있습니다 (독립적이고 의미있는 논리 덩어리로)
• 5 줄보다 작은 함수는 코드를 너무 많이 나눌 수 있다는 힌트입니다 (함수 사이를 탐색 해야하는 경우 읽기 / 이해하기가 더 어려워 짐). 또는 특별한 경우 / 오류 처리를 잊어 버렸습니다!

그러나 규칙에서 벗어나야 할 유효한 예외 / 이유가 항상 있기 때문에 절대 규칙을 설정하는 것이 도움이되지 않는다고 생각합니다.

• 유형 캐스트를 수행하는 한 줄 액세서 기능은 경우에 따라 명확하게 허용됩니다.
• 5 줄 미만을 분명히 필요로하는 매우 짧지 만 유용한 기능 (예 : 사용자가 알 수없는 스왑)이 있습니다. 큰 문제는 아니지만 몇 가지 3 줄 함수는 코드 기반에 해를 끼치 지 않습니다.
• 하나의 큰 switch 문인 100 행 함수는 수행중인 작업이 매우 분명한 경우 허용 될 수 있습니다. 이 코드는 다른 경우를 설명하기 위해 많은 행이 필요하더라도 개념적으로 매우 간단 할 수 있습니다. 때로는 이것이 별도의 클래스로 리팩토링되고 상속 / 다형성을 사용하여 구현되어야한다고 제안하지만 IMHO는 OOP를 너무 많이 취하고 있습니다 .40 개의 새로운 클래스보다 하나의 큰 40-way switch 문만 가지고 싶습니다. 40-way switch 문으로 작성하십시오.
• 복잡한 함수에는 여러 함수간에 매개 변수로 전달되는 경우 매우 혼란 스러울 수있는 상태 변수가 많이있을 수 있습니다. 이 경우 모든 것을 하나의 큰 함수로 유지하면 코드가 더 간단하고 따르기 쉽다는 주장을 합리적으로 만들 수 있습니다 (Mark는 올바르게 지적했지만이 논리를 캡슐화하기 위해 클래스로 전환하는 후보가 될 수도 있음) 그리고 상태).
• 때때로 더 작거나 큰 함수는 성능상의 이점을 제공합니다 (Frank에서 언급 한 인라인 또는 JIT 이유로 인해). 이는 구현에 따라 크게 다르지만 차이를 만들 수 있습니다. 벤치마킹해야합니다!

따라서 기본적으로 상식을 사용 하고 대부분의 경우 작은 기능 크기를 고수하지만 비정상적으로 큰 기능을 수행 해야하는 진정한 이유가 있다면 독단적 인 것은 아닙니다.

올바른 LOC 번호에 대한 엄격한 규칙이 없다고 말했을 때 다른 사람들의 의견에 동의하지만 과거에 보았던 프로젝트를 되돌아보고 위의 모든 기능을 식별하면 150 줄의 코드를 말하겠습니다. 우리는 이러한 기능 중 10 개 중 9 개가 SRP를 깨고 (OCP도 가능성이 높음) 로컬 변수가 너무 많고 제어 흐름이 너무 많으며 일반적으로 읽고 유지하기 어렵다는 의견에 동의 할 것입니다.

따라서 LOC는 잘못된 코드를 직접 나타내는 지표는 아니지만 특정 기능을 더 잘 작성할 수있는 적절한 간접 지표입니다.

팀에서 나는 리드의 위치에 빠졌고 어떤 이유로 든 사람들이 내 말을 듣고있는 것 같습니다. 내가 일반적으로 정한 것은 팀에 절대적인 제한이 없지만 코드 검토 중에 50 줄 이상의 코드가 있으면 최소한 붉은 깃발을 올려야한다는 것을 알려주는 것입니다. 따라서 다시 살펴보고 다시 평가하십시오. 복잡성과 SRP / OCP 위반 두 번째 모습을보고 난 후에 우리는 그것을 내버려 두거나 바꿀 수도 있지만 적어도 사람들이 이런 것들에 대해 생각하게합니다.

코딩 지침에 관심이없는 프로젝트를 시작했습니다. 코드를 살펴보면 때로는 6000 줄 이상의 코드와 10 개 미만의 메서드가있는 클래스를 찾습니다. 이것은 버그를 수정해야 할 때의 공포 시나리오입니다.

방법의 최대 크기에 대한 일반적인 규칙은 때로는 그리 좋지 않습니다. 나는 Robert C. Martin (Uncle Bob)의 규칙을 좋아한다. "방법은 작고 작아야한다" 이 규칙을 항상 사용하려고합니다. 내 방법이 한 가지 일만하고 더 이상 아무것도하지 않음을 분명히하여 내 방법을 단순하고 작게 유지하려고합니다.

줄 수에 관한 것이 아니라 SRP에 관한 것입니다. 이 원칙에 따르면, 방법은 한 가지만 수행해야합니다.

당신의 방법이 이것을하고 이것을 하고이 OR 저것 => 그것은 아마도 많은 것을하고 있습니다. 이 방법과 분석을 살펴보십시오. "여기서이 데이터를 가져 와서 정렬하고 필요한 요소를 얻습니다"및 "여기서 이러한 요소를 처리합니다"와 "결과를 얻기 위해 마지막으로 이들 요소를 결합합니다". 이러한 "블록"은 다른 방법으로 리팩토링되어야합니다.

SRP를 따르기 만하면 대부분의 방법이 작고 분명한 의도로 사용됩니다.

"이 방법은> 20 줄이므로 잘못되었습니다"라고 말하는 것이 올바르지 않습니다. 할 수있다 표시 무언가가 있다고 할 수있다 더 이상,이 방법으로 잘못된.

방법에 400 회선 스위치가있을 수 있으며 (종종 텔레콤에서 발생) 여전히 단일 책임이며 완벽하게 정상입니다.

그것은 의존 정말 문제와 작업입니다 언어, 언급 라인 열 다섯 다섯 때문에이 질문에 대한 확고한 답이없는, 심각, 이 대답은 C #이나 자바하지만 다른 언어로는 제공하지 않습니다 작동 할 수는 당신은 많은 일을합니다. 마찬가지로, 작업중인 도메인에 따라 큰 데이터 구조로 코드 설정 값을 작성하는 경우가있을 수 있습니다. 일부 데이터 구조를 사용하면 설정해야 할 수십 가지 요소가있을 수 있습니다. 함수가 오래 실행되어 기능을 분리하기 위해 분리해야합니까?

다른 사람들이 지적했듯이, 경험상 가장 좋은 규칙은 함수가 단일 작업을 처리하는 단일 논리 엔터티 여야한다는 것입니다. 함수가 n 줄 보다 길 수 없다고 말하는 드라코 니안 규칙을 시행하려고 시도 하고 그 값을 너무 작게하면 개발자가 규칙을 피하기 위해 멋진 속임수를 사용하려고 할 때 코드를 읽기가 더 어려워집니다. 마찬가지로, 너무 높게 설정하면 문제가되지 않으며 게으름에도 불구하고 잘못된 코드로 이어질 수 있습니다. 가장 좋은 방법은 코드 검토를 수행하여 기능이 단일 작업을 처리하고 그대로 두는 것입니다.

여기서 한 가지 문제는 함수의 길이가 복잡성에 대해 아무 것도 말하지 않는다는 것입니다. LOC (라인 코드)는 무엇이든 측정하기에 나쁜 도구입니다.

방법은 지나치게 복잡해서는 안되지만 긴 방법을 쉽게 유지 관리 할 수있는 시나리오가 있습니다. 다음 예제에서는 메소드로 분할 할 수 없으며, 메소드가 유지 보수성을 변경하지 않는다고 말합니다.

예를 들어 들어오는 데이터에 대한 처리기는 큰 switch 문과 사례 당 간단한 코드를 가질 수 있습니다. 피드에서 들어오는 데이터를 관리하는 코드가 있습니다. 숫자로 코딩 된 핸들러 (70)! 이제 "상수 사용"이라고 말할 것입니다. API가 제공하지 않고 여기서 "소스"에 가깝게 유지하는 것을 제외하고는 그렇습니다. 행동 양식? 물론 슬프게도 모두 2 개의 거대한 구조의 데이터를 처리합니다. 더 많은 방법 (가독성)을 갖는 것을 제외하고는 그것들을 나누는 데 아무런 이점이 없습니다. 코드는 본질적으로 복잡하지 않습니다. 필드에 따라 하나의 스위치입니다. 그런 다음 모든 경우에는 데이터의 x 요소를 구문 분석하고 게시하는 블록이 있습니다. 유지 보수의 악몽이 없습니다. 필드에 데이터가 있는지 여부를 결정하는 조건이 하나만 있으면 반복됩니다. pField-> IsSet () {blabla} 인 경우 pField = pFields [x]-모든 필드에서 거의 동일합니다.

중첩 루프를 포함하는 훨씬 더 작은 루틴과 많은 실제 스위칭 명령문으로 대체하면 큰 메소드는 하나의 작은 것보다 유지 관리하기가 더 쉬울 수 있습니다.

죄송합니다. LOC는 좋은 측정 방법이 아닙니다. 그렇다면 복잡성 / 의사 결정 지점을 사용해야합니다.

나는 또 다른 인용문을 던질 것이다.

사람들이 읽을 수 있도록, 그리고 기계가 실행할 수 있도록 프로그램을 작성해야합니다.

-해롤드 아벨 슨

100-200으로 증가하는 기능이이 규칙을 따르는 것은 매우 불가능합니다

나는 1970 년부터이 미친 라켓에 왔습니다.

지금까지 두 가지 예외를 제외하고는 항상 잘 디자인 된 "루틴"(메소드, 프로 시저, 함수, 서브 루틴 등)을 한 페이지 이상 인쇄해야하는 것을 본 적이 없습니다. 약 60 줄). 그들 중 대다수는 10-20 줄 정도의 짧은 시간이었습니다.

그러나 나는 모듈화에 대해 들어 본 적이없는 사람들이 작성한 "의식의 흐름"코드를 많이 보았다.

두 가지 예외는 매우 특별한 경우였습니다. 하나는 실제로 예외로 분류되는 클래스입니다. 큰 유한 상태 오토마타는 큰 추악한 switch 문으로 구현됩니다. 일반적으로 더 명확한 방법이 없기 때문입니다. 이러한 것들은 일반적으로 테스트 대상 장치의 데이터 로그를 분석하여 자동화 된 테스트 장비에 나타납니다.

다른 하나는 CDC 6600 FORTRAN IV로 작성된 Matuszek-Reynolds-McGehearty-Cohen STARTRK 게임의 광자 어뢰 루틴이었습니다. 커맨드 라인을 파싱 한 다음, 섭동으로 각 어뢰의 비행을 시뮬레이션하고 어뢰와 충돌 할 수있는 각 종류의 상호 작용을 확인해야합니다. 다른 별들 옆에있는 별을 어뢰에서 발사하는 것.

긴 방법을 찾으면이 방법이 제대로 단위 테스트되지 않았거나 대부분 단위 테스트를 전혀하지 않은 것이 좋습니다. TDD를 시작하면 25 개의 서로 다른 책임과 5 개의 중첩 루프가있는 100 줄 방법을 만들 수 없습니다. 테스트는 지속적으로 엉망을 리팩터링하고 아저씨의 밥 클린 코드를 작성해야합니다.

메소드의 길이에 대한 절대 규칙은 없지만 다음 규칙이 유용했습니다.

1. 함수의 주요 목적은 반환 값을 찾는 것입니다. 그것이 존재하는 다른 이유는 없습니다. 그 이유가 완전히 채워지면 다른 코드를 삽입해서는 안됩니다. 이것은 반드시 기능을 작게 유지합니다. 다른 함수 호출은 리턴 값을 쉽게 찾을 수있는 경우에만 수행해야합니다.
2. 반면에 인터페이스는 작아야합니다. 이것은 많은 클래스가 있거나 큰 기능을 가지고 있음을 의미합니다. 두 가지 중 하나는 중요한 일을하기에 충분한 코드를 갖기 시작하면 발생합니다. 큰 프로그램은 둘 다 가질 수 있습니다.

저자는 "기능"과 "루틴"이 같은 의미입니까? 일반적으로 "함수"라고 말하면 값을 반환하지 않는 (및 호출이 단일 명령문이되는) "프로 시저"를 리턴하는 서브 루틴 / 작업을 의미합니다. 이것은 실제 세계에서 SE 전체의 공통된 차이점은 아니지만 사용자 텍스트에서 보았습니다.

어느 쪽이든, 이것에 대한 정답은 없습니다. 하나 또는 다른 것에 대한 선호 (기본 설정이있는 경우)는 언어, 프로젝트 및 조직간에 매우 다를 것으로 예상되는 것입니다. 모든 코드 규칙과 마찬가지로.

내가 추가 할 한 가지 비트는 전체 "긴 작업은 짧은 작업보다 더 오류가 발생하기 쉽지 않다"는 주장이다. 더 많은 코드가 더 많은 잠재적 오류 공간과 동일하다는 사실 외에도 코드를 세그먼트로 나누면 오류를 피하기 쉽고 더 쉽게 찾을 수 있다는 것이 맹목적으로 명백합니다. 그렇지 않으면 코드를 조각으로 나눌 이유가 없으므로 반복을 저장하십시오. 그러나 이는 실제 세그먼트 (코드 영역 간의 구체적인 종속성이 아니라 사양을 기반으로 계약별로 설계)를 읽거나 추적하지 않고 오퍼레이션 호출의 결과를 판별 할 수있을 정도로 해당 세그먼트가 충분히 문서화되어있는 경우에만 해당됩니다.

또한 더 긴 작업이 제대로 작동하려면 더 엄격한 코드 규칙을 채택하여이를 지원할 수 있습니다. 작업 중간에 return 문을 던지는 것은 짧은 작업에는 좋을 수 있지만, 더 긴 작업에서는 조건부이지만 빠른 읽기에 대한 조건부로 보이지 않는 큰 코드 섹션을 만들 수 있습니다 (예를 들어).

그래서 어떤 스타일이 버그로 가득 찬 악몽이 될 가능성이 적다고 생각할지는 나머지 코드에 대해 어떤 규칙을 준수하는지에 달려 있습니다. :)

IMHO, 스크롤 막대를 사용하여 기능을 읽을 필요는 없습니다. 스크롤바를 움직여야 할 때 기능 작동 방식을 이해하는 데 시간이 더 걸립니다.

따라서 팀 작업의 일반적인 프로그래밍 환경 (화면 해상도, 편집기, 글꼴 크기 등)에 따라 다릅니다. 80 년대에는 25 개의 줄과 80 개의 열이있었습니다. 이제 편집기에서 거의 50 줄을 표시합니다. 한 번에 두 개의 파일을 표시하기 위해 화면을 두 개로 나누면 표시되는 열 수가 변경되지 않았습니다.

간단히 말해 동료의 설정에 따라 다릅니다.

나는 TomTom의 대답 이 그것에 대해 어떻게 느끼는지에 가깝다고 생각 합니다.

점점 더 나는 선이 아닌 순환 적 복잡성을 겪고 있습니다.

나는 일반적으로 다차원 배열을 처리하는 데 필요한 많은 루프를 제외하고 메소드 당 하나 이상의 제어 구조를 목표로합니다.

때로는 스위치 라인에 한 줄 ifs를 넣는 것을 발견합니다. 왜냐하면 어떤 이유로 든 도움이되지 않고 방해하는 경우가 있기 때문입니다.

이 제한에 대해 가드 로직을 계산하지 않습니다.

OOP에는 모든 것이 반대되며 다음과 같은 기능이 있습니다.

1. 다형성
2. 추출
3. 계승

이러한 규칙을 준수하면 일반적으로 방법이 작지만 작거나 매우 작은 (예 : 2-3 줄) 규칙에 대한 규칙은 없습니다. 작은 방법 (소형 단위, 예 : 방법 또는 기능)의 이점은 다음과 같습니다.

1. 더 읽기 쉬운
2. 더 나은 유지
3. 더 나은 버그 수정
4. 더 나은 변화