함수의 최대 길이로 입증 된 것은 무엇입니까? [닫은]

함수 길이가 프로그래머의 생산성에 영향을 줍니까? 그렇다면 생산성 손실을 피하기위한 최대 라인 수는 얼마입니까?

이것은 매우 의견이 많은 주제이므로 일부 데이터로 주장을 백업하십시오.

1970 년에이 미친 라켓을 시작한 이래로, 실제로 하나 이상의 인쇄 된 페이지 (약 60 줄)가 필요한 하나의 모듈을 보았습니다 . 더 긴 모듈을 많이 보았습니다.

그 문제에 대해서는 더 긴 모듈을 작성했지만 일반적으로 큰 스위치 상태로 작성된 대형 유한 상태 머신이었습니다.

문제의 일부는 요즘 프로그래머가 물건을 모듈화하도록 가르치지 않았다는 것 같습니다.

수직 공간 낭비를 최대화하는 코딩 표준도 문제의 일부인 것으로 보입니다. (저는 Gerald Weinberg 의 " 컴퓨터 프로그래밍의 심리학 "을 읽은 소프트웨어 관리자를 아직 만나지 못했습니다 . Weinberg는 여러 연구에서 프로그래머의 이해가 본질적으로 프로그래머가 특정 순간에 볼 수있는 것으로 제한됨을 보여주었습니다. 프로그래머는 페이지를 스크롤하거나 페이지를 넘기면 이해력이 크게 떨어집니다. 기억하고 추상화해야합니다.)

FORTH 로부터 많은 문서화 된 프로그래머의 생산성 향상은 소스 코드에 대한 FORTH "블록"시스템으로 인한 것이라고 확신합니다 . 모듈은 최대 16 줄의 64 자로 제한되었습니다. 무한히 고려할 수는 있지만 어떤 상황에서도 17 줄 루틴을 작성할 수는 없습니다 .

정말로 적당한 크기는 무엇입니까?

사용하는 언어에 따라 다르지만 일반적으로 (나의 개인적인 취향에 따라) :

• 이상적으로 , 25 줄 미만.
• 수용 가능한 미만의 35 개 라인.

더 있다면 나중에 돌아와서 다시 작업해야 할 문제입니다.

그러나 현실적으로 , 당신이 무언가를 전달해야 할 때 필요하고 어떤 식 으로든 뱉어내는 것이 더 합리적이라고 생각하는 모든 크기는 때로는 선적하기 전에 누군가가 검토하기를 더 쉽게 만듭니다. (그러나 여전히 나중에 다시 가져옵니다).

(최근에 우리 팀은 코드베이스에서 프로그램을 실행했습니다. 우리는 197 개의 메소드를 가진 클래스를 찾았고 3 개의 메소드 만있는 클래스를 찾았지만 그 중 하나는 600 줄이었습니다. 귀여운 게임 : 2 악의 더 나쁜 점은 무엇입니까?)

이제 더 많은 대답을 얻으려면 ... 일반적으로 한 두 명의 위대한 인물을 인용하는 것이 좋습니다 (TM)으로 간주되므로 다음과 같습니다.

모든 것이 가능한 한 단순해야하지만 단순하지 않아야합니다. - 아인슈타인

더 이상 추가 할 항목이 없을 때가 아니라 더 이상 제거 할 항목이 없을 때 완벽하게됩니다. - 생 텍쥐페리 드 A.

주석 스타일에 대한 부록

이것에 대한 부록으로서, 함수는 그 의도를 설명하는 명확한 이름을 가져야합니다. 주석과 관련하여 일반적으로 함수 내부에는 주석을 달지 않습니다.

• 코멘트 말 "왜?" ,
• 코드 는 "어떻게?" .

각 기능의 맨 위에있는 설명 블록 (설명 필요)으로 충분합니다. 함수가 작고 함수 이름이 충분히 명시 적이라면 달성하고자하는 것과 그 이유를 말하면됩니다. 의도가 불분명 한 경우 25-35 라인 규칙을 위반하는 함수의 경우 일부 언어의 필드 또는 블록 시작에 대해서만 인라인 주석을 사용합니다. 예외적 인 상황이 발생할 때 코드 내에서 블록 주석을 사용합니다 (예를 들어 필요하지 않거나 수행하려는 catch 블록은 이유를 알려주는 주석이 있어야 함).

자세한 내용 은 스타일 및 주석 코드 권장 사항에 대한 답변 을 읽으십시오.

제 생각에는 모든 기능은 가능한 한 작아야합니다. 각 기능은 한 가지 작업 만 수행하고 잘 수행해야합니다. 그것은 최대 길이 질문에 실제로 대답하지는 않지만 기능의 길이에 대한 나의 감정입니다.

밥 아저씨의 말을 사용하려면 "더 이상 추출 할 수 없을 때까지 추출하십시오. 떨어질 때까지 추출하십시오."

건물의 최대 높이는 얼마입니까? 빌드 위치 또는 원하는 높이에 따라 다릅니다.
다른 도시에서 온 다른 사람들로부터 다른 답변을 얻을 수 있습니다.
일부 스크립트 함수 및 커널 인터럽트 처리기는 매우 깁니다.

나를 위해 작동하는 방법은 다음과 같습니다. 더 긴 기능의 일부가 의미있는 이름을 줄 수 있습니까? 나는 방법의 길이가 좋은 명명과 같이 중요하지 않다고 생각합니다. 이 방법은 이름이 말하는 것을 더 이상해서는 안됩니다. 그리고 당신은 좋은 이름을 줄 수 있어야합니다. 메소드의 이름을 적절하게 지정할 수 없으면 코드가 잘 맞지 않을 수 있습니다.

필요한 작업을 수행해야하는 한 더 이상 필요하지 않습니다.

트레이드 오프가 있다고 생각합니다. 짧은 메소드가 많으면 하나의 긴 메소드보다 디버그하기가 더 어렵습니다. 하나의 메소드 호출을 추적하기 위해 편집기를 20 또는 30 번 서로 다른 곳으로 이동해야하는 경우,이를 모두 머리 속에 두는 것은 어렵습니다. 한편 잘 작성된 명확한 방법이 있다면 100 줄이더라도 머리에 두는 것이 더 쉽습니다.

실제 질문은 왜 항목이 다른 방법으로 이루어져야하는지, 위의 답변은 코드 재사용입니다. 코드를 다시 사용하지 않거나 알지 못하는 경우 하나의 거대한 방법으로 코드를 남기고 재사용해야 할 때 재사용해야 할 부분을 분할하는 것이 좋습니다. 더 작은 방법으로 사용합니다.

실제로 좋은 방법 설계의 일부는 기능적으로 응집력있는 방법을 만드는 것입니다 (본질적으로 한 가지 일을합니다). 방법의 길이는 중요하지 않습니다. 함수가 잘 정의 된 것을 수행하고 1,000 줄이면 좋은 방법입니다. 함수가 3 개 또는 4 개의 작업을 수행하고 15 행에 불과하면 나쁜 방법입니다 ...

전체 기능을 한 번에 볼 수 있다면 내가하고있는 일을 추적하는 것이 더 쉽다는 것을 알게되었습니다. 다음은 함수 작성을 선호하는 방법입니다.

1. 합리적인 글꼴로 모니터에 맞도록 짧습니다.
2. # 1보다 길어야하는 경우 적절한 글꼴로 종이에 인쇄 할 수있을 정도로 짧습니다.
3. # 2보다 길어야하는 경우 한 장의 용지에 2 장 인쇄 할 수있을 정도로 짧습니다.

그보다 더 긴 함수는 거의 쓰지 않습니다. 이들 중 대부분은 거대한 C / C ++ 스위치 문입니다.

나를 위해, 함수는 필요한 길이입니다. 내가 나누는 대부분의 시간은 코드를 재사용 할 때입니다.

기본적으로 나는 '높은 응집력, 낮은 결합력'을 고수하고 길이에 대한 제약은 없습니다.

문제는 함수가 얼마나 많은 작업을 수행해야 하는가하는 것입니다. 일반적으로 "한"작업을 수행하기 위해 100 줄이 필요한 경우는 거의 없습니다. 다시 말하지만 코드를 보는 수준에 따라 다릅니다. 암호 해싱이 한 가지입니까? 아니면 암호를 해시하고 저장하는 것이 하나입니까?

암호를 하나의 기능으로 저장하는 것으로 시작하십시오. 해싱이 다르다고 생각하고 코드를 리팩터링하십시오. 나는 어떤 방법으로도 전문 프로그래머가 아니지만 IMHO, 함수의 전체 아이디어는 작게 시작합니다. 함수가 많을수록 코드 재사용 가능성이 높고 두 곳 이상에서 동일한 변경을 할 필요가 없습니다. 등

1000 줄 이상을 실행하는 SQL 저장 프로 시저 를 보았습니다 . 저장 프로 시저 줄 수도 50보다 작습니까? 모르겠지만 코드를 읽습니다. 위 아래로 스크롤해야 할뿐만 아니라 "this does validate1", "this update in the database"등과 같은 몇 줄의 코드를 프로그래머에게 제공해야합니다.

에서 복잡성을 (위키 백과)

소스 코드 섹션의 순환 복잡도는 소스 코드를 통한 선형으로 독립적 인 경로의 수입니다.

• 단일 방법으로 해당 숫자를 10 미만으로 유지하는 것이 좋습니다. 10에 도달하면 리팩터링해야합니다.

• 코드를 평가하고 순환 복잡도를 제공 할 수있는 도구가 있습니다.

• 이러한 도구를 빌드 파이프 라인에 통합하려고 노력해야합니다.

• 말 그대로 메소드 크기를 쫓지 말고 복잡성과 책임을 살펴보십시오. 하나 이상의 책임이있는 경우 리팩토링하는 것이 좋습니다. 순환 복잡성이 증가하면 리팩토링해야 할 때입니다.

• 비슷한 피드백을 제공하는 다른 도구가 있다고 확신하지만 아직 조사 할 기회가 없었습니다.

일반적으로 메서드 / 기능을 1680x1050 모니터 화면에 맞는 것으로 유지하려고합니다. 맞지 않으면 도우미 메소드 / 함수를 사용하여 작업을 소포하십시오.

화면과 종이 모두에서 가독성을 향상시킵니다.

올바르게 최적화 될 수있을 정도로 짧음

정확히 한 가지 작업을 수행 할 수있는 방법은 짧아야합니다. 그 이유는 간단합니다. 따라서 코드를 올바르게 최적화 할 수 있습니다.

Java 또는 C #과 같은 JIT 언어에서는 JIT 컴파일러가 코드를 빠르게 생성 할 수 있도록 메소드가 단순해야합니다. 길고 복잡한 방법은 자연스럽게 더 많은 JIT 시간이 필요합니다. 또한 JIT 컴파일러는 소수의 최적화 만 제공하며 가장 간단한 방법 만이 기능을 활용할 수 있습니다. 이 사실은 Bill Wagner의 Effective C # 에서도 나타났습니다 .

C 또는 C ++와 같은 저수준 언어에서는 짧은 방법 (수십 줄 정도)을 갖는 것도 중요합니다. 이렇게하면 레지스터가 아닌 RAM에 로컬 변수를 저장할 필요가 최소화되기 때문입니다. (일명 '유출 등록')이 관리되지 않는 경우 각 함수 호출의 상대 비용이 상당히 높을 수 있습니다.

루비 나 파이썬과 같은 동적 언어에서도 짧은 메소드를 사용하면 컴파일러 최적화에도 도움이됩니다. 동적 언어에서는 기능이 '동적'일수록 최적화하기가 더 어렵습니다. 예를 들어, X를 사용하고 Int, Float 또는 String을 반환 할 수있는 긴 메서드는 각각 단일 형식 만 반환하는 세 개의 개별 메서드보다 훨씬 느리게 수행됩니다. 컴파일러가 함수가 반환 할 형식을 정확히 알고 있으면 함수 호출 사이트도 최적화 할 수 있기 때문입니다. 예를 들어 유형 변환을 확인하지 않습니다.

일부 함수는 본질적으로 복잡한 알고리즘을 구현하고 더 짧게 만들려고하면 새로운 짧은 함수 간의 상호 작용이 너무 복잡해져 순 결과가 단순하게 줄어들지 않기 때문에 어떤 것도 하드 라인 제한을 두지 않습니다. 또한 높은 수준의 추상화에서 "하나의 것"이 낮은 수준에서 "많은 것"일 수 있기 때문에 함수가 "하나의 것"만 수행해야한다는 생각이 좋은 가이드라고 생각하지 않습니다.

나에게 길이가 DRY를 미묘하게 위반하면 함수가 너무 길어서 함수의 일부를 새로운 함수 또는 클래스로 추출하면이를 해결할 수 있습니다. 그렇지 않은 경우 함수가 너무 길 수 있지만 함수 나 클래스를 쉽게 추출 할 수 있으므로 코드를 모듈 식으로 만들 수있어 예측 가능한 변경에 직면 할 경우 유용합니다.

그것은 코드에 무엇이 있는지에 달려 있습니다.

나는 아무런 문제가없는 천 줄의 루틴을 보았습니다. 그것은 거대한 스위치 문장이며, 옵션은 12 줄을 초과하지 않았으며 모든 옵션의 유일한 제어 구조는 단일 루프였습니다. 요즘에는 객체로 작성되었지만 그 당시에는 옵션이 아니 었습니다.

나는 또한 내 앞에서 스위치에서 120 라인을보고 있습니다. 가드, 과제, 휴식 등 3 줄을 넘지 않아야합니다. 텍스트 파일을 구문 분석하고 객체를 사용할 수 없습니다. 다른 대안은 읽기가 더 어렵다.

대부분의 컴파일러는 함수의 길이를 신경 쓰지 않습니다. 기능은 기능적이어야하지만 이해하기 쉽고 사람에게 변화와 재사용이 용이해야합니다. 가장 적합한 길이를 선택하십시오.

내 일반적인 규칙은 기능이 화면에 맞아야한다는 것입니다. 이것을 위반하는 경향이있는 세 가지 경우가 있습니다 :

1) 디스패치 기능. 옛날에는 이것들이 일반적 이었지만 요즘 대부분은 객체 상속으로 대체되었습니다. 그러나 객체는 프로그램 내에서만 작동하므로 다른 곳에서 도착한 데이터를 처리 할 때 가끔 디스패치 기능이 표시됩니다.

2) 목표를 달성하기 위해 전체 단계를 수행하고 단계가 세분화되지 않은 기능. 당신은 단순히 다른 함수의 긴 목록을 순서대로 호출하는 함수로 끝납니다.

3) # 2와 비슷하지만 개별 단계가 너무 작아서 개별적으로 호출되는 것이 아니라 단순히 인라인됩니다.

아마도 함수 길이가 그리 좋지 않을 수도 있습니다. 우리는 메소드에서도 사이클로 매틱 복잡성 을 사용하려고하며 클래스와 메소드에서 사이클로 매틱 복잡성이 X보다 낮아야한다는 미래의 소스 제어 체크인 규칙 중 하나입니다.

방법의 경우 X는 30으로 설정되어 있으며 매우 빡빡합니다.