코드 파일이 어느 시점 / 범위에 있습니까?

2-3k 라인 파일을 많이 찾고 있는데 실제로 그렇게 커야한다고 생각하지 않습니다.

소스 코드 파일을 "너무 큰"객관적으로 호출하기위한 좋은 기준은 무엇입니까? 소스 코드 파일에 있어야하는 최대 행 수와 같은 것이 있습니까?

이상적인 모델로서 나는 다음과 같은 기준을 사용합니다 (마틴 베켓이 제안한 것과 유사한 근거, 즉 코드 구조가 아닌 논리적 구조에 대한 생각) :

규칙 1

파일 당 하나의 클래스 (C ++에서 하나의 클래스-> 하나의 헤더와 하나의 구현 파일)

규칙 2

일곱은 우리 뇌가 혼란스럽지 않고 동시에 관찰 할 수있는 항목의 수로 간주됩니다. 7 이상에서는 우리가 보는 것에 대한 개요를 유지하기가 어렵습니다. 따라서 각 클래스에는 7-10 개 이상의 메서드가 없어야합니다. 메소드가 10 개를 초과하는 클래스는 아마도 너무 복잡하므로 분할하려고 시도해야합니다. 분할은 클래스를 분할 할 때마다 각 개별 클래스의 복잡성을 최소한 2 배 줄이므로 매우 효과적인 방법입니다.

규칙 3

하나 또는 두 개의 화면에 맞지 않는 메소드 본문이 너무 큽니다 (화면 / 편집기 창이 약 50 줄이라고 가정합니다). 이상적으로는 전체 방법을 한 창에서 볼 수 있습니다. 그렇지 않은 경우 숨겨지는 메소드 부분을 잊지 않고 약간 위아래로 스크롤하면됩니다. 따라서 전체 분석법 본문을 읽기 위해 둘 이상의 화면을 위나 아래로 스크롤해야하는 경우 분석법이 너무 커서 개요를 쉽게 잃을 수 있습니다.

다시 개인 도움말 메소드를 사용하여 메소드를 분할하면 메소드 복잡성이 매우 빠르게 감소 할 수 있습니다 (매 분할마다 복잡성이 절반으로 줄어 듭니다). 개인 도움말 메소드를 너무 많이 도입하면 별도의 클래스를 작성하여 수집 할 수 있습니다 (공용 메소드보다 개인 메소드가 더 많은 경우 두 번째 클래스가 기본 클래스에 숨어있을 수 있음).

이 대략적인 추정치를 정리하면 다음과 같습니다.

• 소스 파일 당 최대 하나의 클래스
• 수업 당 최대 10 개의 공개 방법.
• 클래스 당 최대 10 개의 개인용 메소드.
• 방법 당 최대 100 줄.

따라서 2000 줄 이상의 소스 파일이 너무 커서 너무 지저분 해지기 시작합니다.

이것은 실제로 매우 거친 추정치이며 체계적으로 이러한 기준을 따르지 않습니다 (특히 적절한 리팩토링을 수행 할 시간이 항상 충분하지 않기 때문에). 또한 Martin Beckett이 제안했듯이 클래스가 많은 메소드 모음이며 클래스를 더 작게 만들기 위해 인위적인 방식으로 나누는 것이 합리적이지 않은 상황이 있습니다.

어쨌든, 내 경험상 위의 매개 변수 중 하나가 존중되지 않으면 파일을 읽을 수 없게됩니다 (예 : 6 개의 화면에 걸쳐있는 300 줄 메서드 본문 또는 5000 줄 코드가있는 소스 파일).

아니요-코드 줄과 관련이 없습니다. 드라이버는 논리적 그룹이어야합니다. 예를 들어 하나의 큰 파일에 여러 클래스가 없어야합니다.

합법적으로 수백 가지 방법이있는 클래스가 있다면 (3D 모델링에서는 불가능하지는 않습니다) 클래스를 임의의 파일로 분할하는 것이 훨씬 편리하지 않습니다. 우리는 메모리가 부족하고 프로세서 속도가 느릴 때이 작업을 수행해야했습니다.

코드가 유지되지 않으면 즉 : 찾고있는 메소드 / 클래스 / 함수가 있고 편집 / 디버그 해야하는 코드가 있는지 여부와 코드의 위치를 ​​알 수 없습니다.

IDE / Editor의 선택과 기능은이 상한의 실제 수량에 영향을 미칩니다. 코드 폴딩 , 함수 / 메소드 목록 및 조회 는 이 개발 시나리오가 제시하는 순간 을 연기 합니다.

그러나 그렇게 할 때, 그것을 나누어야 할 때입니다.

대체보기는 다음과 같습니다. 파일 크기를 제한하는 방법을 묻습니다. 내 의견은 큰 코드 파일을 매우 문제를 일으키는 많은 요소가 있다는 것입니다. 때로는 코드 파일이 크지 만 내용이 잘 클러스터되어 있고 매우 깨끗한 코드이므로 크기가 큰 문제를 일으키지 않습니다. LOC가 높음에도 불구하고 읽을 수있는 많은 파일을 보았습니다.

LOC 메트릭을 사용하는 대신 이력 데이터를 사용하여 큰 파일에서 코드가 얼마나 자주 손상되는지 이해하려고합니다. 일반적으로 그 이유는 개발자가 동일한 파일에서 관련 다른 위치를 확인하고 충분한 이해없이 "빠른 수정"사고 방식으로 변경할 시간이 없기 때문입니다.

더 큰 위험은 복사-붙여 넣기 코드가 있다는 것입니다. 복사-붙여 넣기 코딩도 당연히 LOC 성장 속도를 높입니다. LOC를 마법의 숫자 이하로 유지하는 것보다 복사 붙여 넣기를 제거하는 것이 더 중요하다고 생각합니다. 순수한 복사-붙여 넣기 외에도 큰 파일에는 두 번째 위험 인 중복되는 기능이 있습니다. 파일이 클수록 이미 같은 파일의 다른 섹션에있는 일부 스 니펫을 다시 구현할 가능성이 높아집니다.

따라서 더 큰 파일에 대해 버그 수정 비율 (모든 커밋에 대한 버그 수정 커밋 비율)이 낮 으면 상황이 허용됩니다. 시도해 git log보고 오류와 관련된 커밋 수를 살펴 보십시오 . 또는 자동 분석 및 시각화 할 수있는 도구 (예 : Softagram)를 사용하십시오 .

이것을 고려하십시오 Metaphor. 코드 길이와 관련하여 다음을 고려해야한다고 생각합니다.

The Cat in The Hat (50 pp.)

과

Lord of The Rings (1,178 pp.)

에 아무런 문제가 없습니다 Lord of the Rings. 멋진 책입니다. The Cat in the Hat또한 훌륭한 책입니다. 둘 다 5 살짜리 어린이들에게 이해 될 수 있지만, 내용 때문에 하나만 더 적합합니다.

요컨대, 코드 작성은 가능할 때마다 5 세가되어야합니다. Cyclomatic Complexity개발자가 코드를 생성 할 때 고려해야 할 중요한 개념입니다. 기능 및 코드 재사용 성을 최대한 향상시키기 위해 라이브러리 활용 및 생성 이런 식으로 우리 코드는 우리가 작성한 것보다 많은 양을 말할 수 있습니다.

우리 대부분은 어셈블리 코드를 작성하지 않습니다 . 그러나 코드의 근본은 어셈블리입니다. 10000 라인 어셈블리를 통한 검색은 올바르게 수행되면 10000 라인의 파이썬보다 어렵습니다.

그러나 일부 작업에는 500 ~ 1000 줄을 작성해야합니다. 코드의 목표는 300 줄의 깨끗한 코드를 작성하는 것입니다.

개발자로서 우리는 "반지의 제왕"을 쓰고 싶습니다. 버그가 생길 때까지 "Cat in the Hat"을 쓰고있었습니다. 코딩을 자아의 척도로 만들지 마십시오. 간단한 방식으로 작업을 수행하십시오.

개발자는 코드를 문서화하고 싶지 않습니다 (문서화 된 코드를 개인적으로 좋아합니다. 저는 이기적이지 않습니다). 따라서 이해하고 읽을 수있는 코드는 작성하지 마십시오. Cat in the Hat코드를 작성 하십시오.

우리 모두는 당신이 JRR Tolken (머리에 있음)을 알고 있습니다 . 버그가없는 코드로는 증명할 것이 없습니다.

은유의 또 다른 이유.

독자에게 부를 퍼 뜨리지 마십시오. 여러 사람들과 함께 일하고 그들 모두가 같은 큰 파일을 변경해야한다면, 아마도 당신은 아마도 git지옥 에 합류 하게 될 것입니다 .

모두는 rebasing을 좋아합니다.

-> 아무도 말하지 않았다!

TL; DR 가독성에 중점을 둡니다. 코드와 도우미를 여러 줄과 파일에 최대한 많이 퍼뜨립니다. 단일 파일에 8 개 또는 9 개의 클래스를 넣지 마십시오. 코드를 읽기 어렵고 유지 관리하기가 어렵습니다. 큰 조건 코드 또는 루프가있는 경우 언어에서 지원하는 경우 Lambdas로 변경하십시오. 유틸리티 기능은 코드 가독성을 높이기위한 훌륭한 수단으로 고려해야합니다. 무거운 중첩을 피하십시오.