함수 당 최적의 코드 줄이 있습니까? [닫은]

18

함수는 코드 중복을 최소화하는 데 사용될뿐만 아니라 긴 함수를 작은 함수로 분할하여 가독성을 높이고 코드 자체 주석을 작성하는 데 사용됩니다. 그러나이 이득은 기능 또는 방법 당 LOC 수에 반비례하지 않습니다. 그렇지 않으면 우리는 한 줄 또는 두 줄의 코드 만 포함하는 수많은 함수를 갖게 될 것입니다.

이로 인해 궁금해 졌습니다. 함수 당 최적의 LOC 수가 있습니까? 그렇다면 무엇이며 언어간에 차이가 있습니까?

functions

— 가 블린
소스

6

좋은 시간을 보려면 Mitch McConnell의 Code Complete Vol 2 7 장 섹션 4를 참조하십시오.

— 피터 터너

2

@

— Peter-

그래, 재밌는 책을 보면서 글을 쓸 것이다 .... Wasnt Mitch McConnell Pres. 부시의 참모장?

— 피터 터너

3

숫자는 언어에 따라 거의 확실하게 다릅니다. 6 줄 Prolog 절을보고 놀랐지 만 20 줄 Delphi 방법으로는 완벽하게 괜찮습니다. 아래 답변은 환경을 사용하여 짧은 방법을 권장하는 스몰 토크에 대한 것입니다.

— Frank Shearar

1

@ 피터 터너 : 흠 ... S1에서 S15까지 그리고 I1에서 I11까지. 임시 변수를 레지스터와 혼동하는 것 같습니다. ^^

— gablin

33

여러 줄 대신에 내가 사용할 기준은 각 함수가 한 가지 작업 만 수행하고 잘 수행해야한다는 것입니다.

— 그로 쿠스
소스

예, 우리가 일 단위를 가지고 있다면 무슨 일이 일어나고 있는지를 이해하기 위해 50 개의 기능 사이를 이동하고 싶지 않습니다. 이 지표를 사용하여 함수를 적절하게 분류하면 거의 자연스럽게 크기가 적당해야합니다.

— ChaosPandion

2

@ChaosPandion : 그러나 작업 단위는 아마도 더 기본적인 단계로 표현 될 수 있습니다. 함수를 검토하는 경우 각 단일 단계의 코드가 아닌 단계 순서를 검토합니다.

— Wizard79

2

@Lorenzo-이 경우 각 단계는 작업 단위가됩니다. 상위 기능은 작업 단위에 대한 상위 레벨 개요가됩니다.

— ChaosPandion

1

예, 이것은 사실입니다. 흠, 다음 질문을 바꾸어 보자. 한 가지 기능 만 수행하는 함수에 대해 최적의 LOC가 있습니까?

— gablin

@gablin, 말하기 어렵고 또한 LOC는 언어에 따라 다르지만이 원칙을 준수하면 일반적으로 1 ~ 50과 같은 합당한 범위 내에있게됩니다.

— grokus

21

오래된 경험 법은 스크롤없이 화면에 기능이 완전히 표시되어야한다는 것입니다.

기본 개념은 한 번에 전체 기능을 볼 수 없으면 기능이 너무 복잡하므로 더 기본적인 부분으로 분할해야한다는 것입니다.

이 규칙은 매우 실용적이고 유용하지만 공식적인 규칙은 함수에서 하나의 논리적 단계 만 유지해야한다는 것입니다. 함수는 기본 작업 만 수행합니다. 작업을 더 많은 기본 조각으로 나눌 수 있으면 기능을 분할해야합니다.

— 마법사 79
소스

21

이 모니터는 평균 모니터 크기 / 해상도가 증가함에 따라 점점 더 쓸모 없게됩니다.

— Adam Lear

2

우리의 프로그래밍 교수는 방금이 예제를 다른 밤에 말했다 :)

— cdnicoll

2

@Anna : 글쎄, 내 모니터는 고해상도이지만 툴바 / 팔레트 / 패널의 수가 증가했습니다. 그런 다음 14pt 피치 글꼴을 사용할 수 있습니다! :)

— Wizard79

4

단말기의 24 x 80 크기는 변하지 않습니다.

— 대안

1

말도 안되는 규칙의 요점은 "스크롤없이 모든 것을 볼 수 있습니다"입니다. 큰 모니터를 사용하면이 규칙을 위반하지 않고도 더 많은 기능을 사용할 수 있습니다. 큰 모니터가 작은 기능 만 볼 수있는 것은 아닙니다 (IDE에있는 모든 도구 모음과 속성 창이 있지만 여전히 그렇습니다 :- ))

— gbjbaanb

15

없습니다.

화면이 커지고 글꼴 크기가 작아집니다. 사람들이 서로 다른 크기의 엄지 손가락을 가지면 엄지 손가락 규칙이 제대로 작동하지 않습니다.

간결합니다. 함수가 여러 가지 작업을 수행하는 경우 더 작은 함수로 나누는 것이 좋습니다.

— 조쉬 케이
소스

당신이 할 수있는 최소한의 이유 는 왜 내 대답이 유용하지 않다고 생각 하는지 알려주십시오 .

— Josh K

7

h1 태그를 사용하여 누군가가 기분을 상하게 한 것 같습니다 .

— ChaosPandion

@ 차오스 : 그게 필수 답입니다.

— Josh K

6

어쩌면 나는 조금 미묘했지만 내 의도는 귀하의 답변에 투표를 할 정당한 이유가 없다는 것을 암시하는 것이 었습니다. 그 행위를 한 사람은 누구든 그렇게 할 개인적인 이유가있었습니다. 그들은 단순히 조쉬가 끔찍한 이름이라고 생각할 수도 있습니다.

— ChaosPandion

6

스몰 토크는 방법의 크기를 줄이는 약간 특이한 방법이 있습니다. 코드를 작성할 때 브라우저라는 위젯에 코드를 작성합니다. 브라우저에는 두 개의 주요 부분이 있으며 가로로 나뉩니다. 코드는 아래쪽에 들어갑니다.

기본적으로 브라우저는 그리 크지 않습니다. 스크롤을 시작하기 전에 5 줄 또는 6 줄을 넣을 수 있습니다. 물론 스크롤은 약간 자극적입니다.

따라서 스몰 토크에서 환경은 최대 약 6 줄의 짧은 방법을 작성하도록 권장합니다. (일반적으로 충분합니다. 스몰 토크는 꽤 간결한 언어입니다.)

— 프랭크 시어
소스

2

메소드에서 이상적인 코드 줄 수는 가변적입니다. 기본적으로 함수 정의 컨텍스트 내에서 수행해야 할 작업을 수행하기에 충분한 코드 만 작성하려고합니다. 나는 이것을 일종의 단일 책임 원칙 으로 생각 하고 클래스 대신 메소드에만 적용됩니다.

메소드에 많은 논리와 완료해야 할 단계가있는 경우 메소드를 여러 개별 단계로 나누는 것이 좋습니다. 이러한 각 단계는 필요에 따라 새로운 방법으로 추출됩니다.

"그렇지 않으면 우리는 한 줄 또는 두 줄의 코드 만 포함하는 수많은 함수를 갖게 될 것입니다."

각 방법이 적을수록 더 쉽게 정의되고 이해하고 관리하기가 더 쉽습니다. 필요한 경우 수백 가지 방법을 사용하는 데 아무런 문제가 없습니다. 또한 앞에서 언급 한 SRP에 따라 메서드가 더 작고 관리하기 쉬운 조각으로 분리 된 경우 새 클래스를 추출하기가 더 쉬워집니다.

— 로빈스
소스

1

대답은 물론 42 입니다.

주의 사항 : 어떤 기능도 SRP를 위반하지 않거나 스패 니치 조사 에 직면해야합니다 .

몇 줄은 줄의 양을 줄이는 방법을 알려줍니다.

개별 섹션을 표시하는 의견이 있습니까? 해당 섹션은 기능이어야합니다.
팩토리 / 빌더 외부에 if-else 체인 또는 스위치 문이 있습니까? 책임 분담에 도움이되는 더 나은 디자인 패턴이 필요할 수 있습니다.
기능을 쉽게 테스트 할 수 있습니까? 함수를 쉽게 테스트 할 수있게되면 분리됩니다.
그것은 복잡하고 sigth (1000 라인 몬스터)에 토지가 없습니까? 스크랩 리팩토링을 수행하십시오. 이는 리팩토링이며 코드 책임에 대한 교육을 받기 위해 절약하지 마십시오.

— 요하네스
소스

1

Nᴏʙᴏᴅʏ는 스페인어를 기대합니다 ... 아 버거 , 여기 조금 늦었 어요 .

— leftaroundabout

0

몇 가지 단서가 있습니다.

함수의 목적과 사용법을 설명하는 주석을 작성하는 데 문제가 있으면 너무 깁니다.
함수에서 코드 섹션의 활동을 설명하는 주석을 작성하려는 경우 함수가 너무 깁니다.
다른 함수에서 코드를 붙여 넣는 경우 둘 다 너무 길다 (해당 코드를 별도의 함수로 추출).
클래스 데이터 멤버를 로컬 변수와 구분하기 위해 코딩 규칙이 필요한 경우 함수가 너무 길고 클래스에 멤버가 너무 많습니다.
함수를 읽는 동안 메모를해야하는 경우에는 너무 깁니다.

각각 한두 줄 길이의 함수 톤을 갖는 것이 반드시 나쁜 것은 아닙니다. 그 작은 기능들이 처음에 예상했던 것보다 훨씬 더 많이 재사용되었다는 것을 알았습니다.

— 케빈 클라인
소스