'권장'파일 길이 및 줄 너비 [닫힘]

주어진 파일에 대한 최대 코드 줄 수에 대한 평판 좋은 소스의 권장 사항을 알고 있다면 궁금합니다. 예를 들어 Google의 Closure Linter는 각 줄이 80자를 초과하지 않는 것이 좋습니다.

파일은 여러 번 사냥하거나 검색 문자열을 기억할 필요없이 어떤 기능이나 방법을 찾을 수있을 정도로 짧아야합니다. 내가 사용하는 메트릭은 파일 내에서 코드를 읽는 데 걸리는 시간과 보내는 시간입니다. 이것이 눈에 띄게되면 파일이나 클래스를 다시 파티션해야합니다.

기본 코드 블록의 적절한 크기는 너비와 높이가 충분히 짧기 때문에 그룹 코드 검토 중에 해당 내장을 투영 할 수 있으며 글꼴이 너무 작아서 뒷면에있는 사람이 없어도 모두 맞도록 할 수 있습니다. 회의실에서 읽을 수 없습니다. 이 크기는 휴대 기기 나 태블릿을 가지고있을 때 일부 코드를 설명하도록 요청받은 경우에도 도움이됩니다.

그러한 것은 없으며, 존재하는 경우 사용중인 언어에 따라 크게 달라집니다 (예 : C # 또는 Java와 같은 어셈블러에서 동일한 작업 수행).

고급 언어의 경우이 SO 토론을 볼 수 있습니다 . Java / C #의 경우 메소드 당 10-20 줄 이 Bob Martin이 권장하는 최대 값입니다. 파일은 관련이 없으며 클래스가 수행해야 할 작업에 따라 다르므로 파일에 대한 토론은 없습니다.

한 줄당 80 자 제한과 관련하여 펀치 카드 시절의 후퇴입니다. 줄이 너무 길어지면 가독성이 떨어집니다.

파일 및 줄 길이는 복잡성의 2 차 효과를 측정 한 것으로 매우 다양합니다. 당신이 목표로 삼아야 할 것은 특정 최대 라인 수가 아닌 불필요한 복잡성이없는 코드입니다.

긴 파일은 메소드, 서브 루틴 또는 클래스가 지나치게 복잡함을 나타냅니다 (너무 많은 일을 수행하거나 충분히 고려하지 않은 등).

긴 줄은 표현이 지나치게 복잡하다는 것을 나타냅니다.

잠재적 인 코드 문제를 나타내는 냄새이며 대상 지표가 잘 정의되어 있지 않습니다.

줄 길이는 전체 줄을보기 위해 화면을 스크롤 할 필요가없는 길이 여야합니다. 모니터 크기와 해상도에 따라 다릅니다.

한 화면에 맞으면 방법과 기능이 가장 좋습니다.

파일이 너무 길어서는 안됩니다. 가장 좋은 것은 클래스와 구현을 이해하기 쉬운 짧은 파일입니다.
10 klines 파일이있는 프로젝트에서 작업 한 후 그것은 매우 복잡한 책을 읽는 것과 같았습니다. 구현으로 인해 얼마나 많은 문제가 발생했는지 알아야합니까?

80 자!

COBOL을 수행했을 때 약 80 페이지 이상 을 청구하는 프로그램의 소스 코드 파일을 보았던 것을 기억합니다 . 물론, 나는 이것이 일반적인 관행에 가깝다는 것을 알 수 없지만 80 문자는 똑같이 어리 석습니다.

클래스 크기보기에서 약 80 개의 속성과 20 개의 메서드가있는 일반적인 Customer 클래스에이 제안을 적용하려고하면 클래스를 다른 여러 클래스로 나누고 코드를 매우 복잡하게 만들어야합니다.

클래스와 메서드를 짧게 유지하려고하지만 줄 길이에 대해서는별로 걱정하지 않습니다. 요즘 와이드 스크린과 긴 식별자에서 80 자 정도가 너무 적다고 생각합니다. 문장을 쉽게 읽을 수 있도록 약간의 작업이 필요하며, 글자 수를 80 자로 제한하면 자주 발생합니다. 줄당 약 120 또는 130 열이 더 합리적이라고 생각합니다.