나는이 두 가지 귀중한 프로그래밍 실습을 자주 듣습니다. (1) 코드 줄은 80 자 이하 여야하며 (2) 변수, 메소드, 클래스 등을 설명하는 이름을 사용해야합니다. , 그들은 종종 서로의 트레이드 오프 인 것 같습니다. 코드를 80 자 / 줄 미만으로 유지하면 설명이 적은 이름을 사용하게됩니다 (각 들여 쓰기가 4 자로 계산되는 Python에서는 더 빠름).하지만 더 설명적인 이름을 사용하면 80 자 이상의 줄로 끝납니다.

그래서 제 질문은이 두 가지 조언 중 어느 것이 선택을해야하는지 준수하는 것이 더 중요하다는 것입니다. 나는 이것을 독립적 인 (취미주의) 프로그래머라고 생각하지만, 더 큰 회사에서 일하는 소프트웨어 엔지니어의 관점에서 더 중요합니다.

들여 쓰기를 줄이고 이름을 설명하고 줄 바꿈을 두려워하지 마십시오.

들여 쓰기를 거의하지 마십시오.

들여 쓰기와 서술 적 명명 사이의 싸움에서 자신을 발견 할 때 종종 한 발짝 물러서서 내 들여 쓰기 수준을 살펴 봅니다. 3 개 또는 4 개 이상의 레벨을 들여 쓰기하는 경우 (2 개의 레벨은 자동이며 불가피한 경우가 많습니다. 읽기 : 클래스 메소드 정의) 코드를 재구성하여 기능을 함수 또는 메소드로 추상화 할 수 있습니다.

당신의 이름은 설명 적입니다

항상 이름을 설명해야합니다. 설명적인 이름은 자체 문서화 코드를 만듭니다. 경우에 따라 이름을 줄이려고 할 수 있지만 가독성이 우선입니다.

줄을 무서워하지 마십시오

젠장. 80자를 넘으면 줄의 공백을 되 찾을 수없는 경우 분리하십시오. 대부분의 언어는 줄 바꿈에 신경 쓰지 않으므로 줄을 여러 줄로 나눕니다. 임의의 위치를 ​​선택하지 마십시오. 사물을 논리적으로 그룹화하고 줄을 끊을 때 다른 수준을 들여 쓰기하십시오.

왜 모두?

우선, "설명 적"과 "자세한"은 동일하지 않습니다. 예를 들어, 꽤 로컬 루프를 작성하는 i경우 루프 변수에 대한 매우 좋은 변수 이름입니다. 루프 변수로 current_iteration_index사용 i하는 것이 보편적으로 받아 들여지고 그 외에 다른 의미가 없기 때문에, 논란의 여지가 있지만 더 명확하고 더 장황하지만 훨씬 더 나쁘고 정보를 전혀 추가하지 않습니다 i.

좋은 변수 이름은 언어 관용구와 코드베이스 규칙에 익숙한 프로그래머가 자신의 역할이 무엇인지 쉽게 추측 할 수 있지만 간결성을 유지하기에 간결하다는 점에서 설명하기 쉽습니다.

원래는 1970 년대 텍스트 터미널의 기술적 한계로 인해 80 자로 제한되었지만 오늘날에도 많은 사람들이 여전히 가치를 지니고 있지만 여전히 기술적 이유가 있지만 (일부 네트워크 프로토콜에서 최대 줄 길이, 특히 전자 메일 관련), 더 강력한 이유는 심리적, 사회적 이유입니다. 66 자 표시 주위의 줄 길이는 자연어 산문에서 가장 편안한 독서 경험을 제공한다는 것이 밝혀졌습니다 (글꼴 크기는 큰 차이를 만들지 않으므로 결과적으로 화면이나 용지 크기도 마찬가지입니다). 80 자 한도는 그와 거의 비슷하지만 일반적인 코드 조각은 일반적으로 최소 1 ~ 2 수준 (들여 쓰기 설정에 따라 4 ~ 16 자 사이)으로 들여 쓰기 때문에,

80 자 라인을 고수하는 또 다른 효과는 상황이 너무 복잡한시기를 나타내는 좋은 지표입니다. 긴 줄은 일반적으로 다음 중 하나에 의해 발생합니다.

• 긴 인수 목록이있는 함수; 가독성이 떨어지고 컴파일러가 잡을 수없는 방식으로 인수 순서를 바꿀 때 미묘한 버그를 쉽게 유발할 수 있기 때문에 이것은 좋은 점이 아닙니다.
• 조건부에서 자주 발견되는 복잡한 표현 (예 :) if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null); 이것 또한 보통 해독하기가 어렵고 코드는 좀 더 구조화 된 것으로 다시 작성되어야합니다. 대부분의 경우 표현식이 너무 많으므로 메소드 나 함수에 포함되어야합니다.
• 함수 호출 또는 표현식에 사용되는 긴 리터럴 (예 :) print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. 리터럴을 변수 또는 상수로 이동하십시오. 여전히 줄 길이를 초과 할 수 있지만 일관되게 수행하는 경우 리터럴의 나머지 부분 만 따르는 경우 독자는 줄의 보이지 않는 부분을 무시해도됩니다. 또는 리터럴을 코드에서 외부 데이터 저장소 (파일, 데이터베이스 등)로 옮기십시오.
• 깊이 중첩 된 명령문, 예를 들어 if클래스 메소드 의 6 가지 레벨의 명령문 (일반 설정의 경우 32 열 들여 쓰기). 다시 말하지만, 딥 네 스팅은 복잡하고 읽기 어려운 코드를 만들며, 전염병처럼 피해야합니다. 간단히 말하면 딥 네 스팅은 인간의 뇌 스택에 넘치게됩니다.

이 모든 것은 궁극적으로 장기적으로 코드베이스에없는 것의 증상이며, 80 자 제한을 적용하면 복잡성과 가독성을 높이는 데 도움이되는 훌륭하고 간단한 방법입니다. (80 열에 완벽하게 읽을 수없는 코드를 작성할 수는 없습니다 : 다양한 난독 화 코드 경연 대회는 명확한 예입니다).

기술적 인 명명은 FAR에 의해 더욱 중요합니다. 대부분의 인터페이스에서 더 긴 줄을보기 위해 스크롤 할 수 있습니다. 어떤 경우에도 시스템이 잘못 명명 된 변수와 함수를 번역하도록 도와 줄 수는 없습니다.

한 줄의 긴 코드를 여러 개의 짧은 코드로 나누는 방법이 많기 때문에 한 줄에 80자가 충족되지 않습니다. 문자,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

함수 호출을 여러 행으로 분할 할 수도 있습니다.

따라서, 기술적 인 명명 규칙과 80 개의 문자 라인은 모순이 없으며, 가독성을 향상시키기 위해 공존 할 수 있습니다.

80 한계는 오래 전에 증가해야 할 것입니다. 이 제한은 모든 식별자의 길이가 8 자로 제한되고 화면 / 프린터에서 하나의 글꼴로 제한된 연령부터 사용됩니다. 글꼴 크기를 변경할 수 없습니다.

하나님, 우리는 지금 다른 스크린과 인쇄 기술을 가지고 있습니다. 우리는 매우 다른 프로그래밍 언어를 가지고 있습니다. 더 이상 80자를 사용할 이유가 없습니다. 최소한 120 자 이상으로 늘리십시오.

그럼에도 불구하고 어려운 한계가되어서는 안됩니다. 당신은 한 줄에 한 캐릭터를 간다? 아무 일도 일어나지 않습니다!

편집하다:

80 문자 제한의 역사에 대한 자세한 답변

위키 백과의 줄당 문자 수

위치 타 주립 대학의 한 연구에 따르면 CPL은 속도와 이해력을 포함하여 가독성에 미치는 영향이 미미한 것으로 나타났습니다. 그러나 선호도를 물었을 때 응답자의 60 %가 연구에 사용 된 최단 (35 CPL) 또는 최장 (95 CPL) 라인에 대한 선호를 나타 냈습니다. 동시에 100 %의 응답자들이이 양 중 하나를 가장 바람직하지 않은 것으로 선택했습니다.