최적의 코드 너비에 대한 연구?

선택한 IDE에서 "오른쪽 여백보기"를 활성화하면 기본적으로 80 자로 설정 될 수 있습니다. 몇 년 전 회사의 표준이었던 것 외에는 아무 이유없이 120으로 바꾸는 경향이 있으며, 다른 회사에서는 다르게 말하지 않았습니다.

제 질문은 코드 판독성을 위해 최적의 최대 너비로 80자를 실제로 보여주는 연구가 있습니까, 아니면이 값이 "항상 그랬던 것"이고 그 이유를 아는 사람이 아무도없는 것입니까? 코드 줄의 너비가 코딩 표준의 일부 여야합니까?

실제로, 80 열이 DOS보다 오래갑니다. 그것은 80 열 장치 인 카드 펀치에서 나옵니다.

그리고 OP의 질문에 대한 답을 얻기 위해, 한 "연구"는 현재 약 600 년 동안 진행되어 왔습니다 – 인쇄 된 책. 이들은 텍스트의 평균 줄 길이가 약 60자인 현재 위치로 수 세기 동안 가독성을 염두에두고 발전해 왔습니다. 따라서 가독성을 높이려면 여백을 좁히십시오.

나중에 소프트웨어를 유지 관리하고 80 자 제한을 유지해야하는 프로그래머에게 자비를 베푸십시오.

80을 선호하는 이유 :

• 랩톱에서 더 큰 글꼴로 읽을 수 있음

• 비교를 위해 두 버전을 나란히 놓을 공간을 남겨 둡니다.

• IDE에서 탐색 뷰를위한 공간 확보

• 임의로 줄 바꿈없이 인쇄합니다 (이메일, 웹 페이지에도 적용됨).

• 한 줄로 복잡성을 제한합니다

• 들여 쓰기를 제한하여 결과적으로 메소드 / 기능의 복잡성을 제한합니다

예, 코딩 표준의 일부 여야합니다.

나는 공부를하지 않지만 내 경험을 이야기 할 것입니다.

텍스트를 다룰 때 가로 스크롤이 지루 하다는 것을 알았습니다 . 코드가 사용될 환경을 살펴보고 해당 컨텍스트를 기반으로 너비 표준을 설정합니다.

내가 XWindows를 이맥스에서 일할 때 예를 들어, 2 개 이맥스 창을 가지고 잘 작동 나란히 항상 있습니다. 그것은 80 자로 제한되었으므로 최대 줄 길이였습니다.

어느 시점에서 나는 Visual Studio에서 1920x1200 화면에서 일했습니다. 모든 도구 창이 한쪽에 도킹되어 최대화되어 있습니다. 두 개의 편집기 창에 약 100 자씩 나란히 충분한 공간이 남아있었습니다.

또한 가장 긴 라인에서 온 것을 발견 긴 매개 변수 목록에 메소드 호출 . 이것은 때때로 코드 냄새입니다 . 아마도 메소드를 리팩터링 해야합니다 .

나와 프로그래머가 고해상도 화면과 선명한 시력을 가지고 있다면 반드시 작은 글꼴과 긴 줄을 사용하십시오. 반대로 짧은 줄이 필요할 수 있습니다.

회사에서 달리 설명하지 않는 한 일반적으로 120-150을 사용합니다. 그러나 그것은 또한 코드의 종류에 달려 있습니다 :

• 나는 (거의) 한 줄에 여러 문장을 사용하지 않습니다
• 긴 줄 (> 12) 만 비슷하게 보이는 줄을 정렬하고 끊을 수없는 경우에만 사용합니다.
• 나는 항상 충분한 공간 / 괄호 등을 사용합니다
• 짧은 이름보다 긴 변수 이름을 선호합니다

몇 년 전까지는 100 개로 제한되었지만 이제는 와이드 스크린이 일반적으로 사용되고 고해상도 모니터 (120)는 랩톱에서도 볼 수 있습니다.

책에 더 많은 수직 공간이 있고 화면에 더 많은 수평 공간이 있기 때문에 화면을 책과 비교하는 것은 실제로 좋지 않습니다. 나는 항상 기능을 최대로 유지하려고합니다. 하나의 보이는 화면.

어쩌면 80 문자가 나쁜 게터 체인을 피하기에 좋은 포인트 일 수도 있습니다.

object.getFoo().getBar().getFooBar().get ...

80 자로 제한하면 누군가가 이러한 변수를 지역화하고 null 검사 등을 수행하지만 대부분의 프로그래머는 다음 행에서 줄 바꿈 할 수 있습니다. 모르겠다

그 외에도 스타 블루가 언급 한 것처럼 80자가 좋습니다. 이것은 코딩 표준에 따라야합니다.

하드웨어 제한과 코드와 자연어를 읽는 방식의 차이점을 무시하면서 줄을 약 80 자로 제한해야하는 세 가지 주요 이유가 있습니다.

1. 인간의 안구는 둥글고 좁고 넓지 않으며 대부분의 해상도가 중간에 있습니다. 한 번에 몇 시간 동안 읽을 때 필요에 따라 하나의 스크롤 막대를 사용하여 짧은 원호로 눈을 쓸어주는 것이 훨씬 편안합니다. 코드의 가독성에 대한 공식적인 연구는 알지 못하지만 모니터에서 2 피트 떨어져 있고 텍스트가 10pt 고정 폭 글꼴 크기 인 100 자 (영문)는 가로 필드의 약 1/3을 차지합니다. 시력, 또는 약 60도 ( 우리의 모든 눈의 해상도가 30도를 벗어난 정도 ).
2. 대부분의 사람들은 직장에서 큰 모니터를 사용하므로 한 번만 클릭해도 큰 화면을 볼 수 있도록 앞뒤로 클릭하지 않고도 여러 항목을 볼 수 있습니다.
3. 줄이 짧을수록 복잡성이 줄어들 기 때문에 개발자가 코드를 더 소화 가능한 단위로 분해해야합니다.

나는 최적의 가독성을 위해 문서의 너비가 약 2 개의 알파벳 또는 60-70 자 여야한다는 어딘가에서 읽은 것을 분명히 기억합니다 ( Agile Documentation 에 있다고 생각합니다 ). 나는 구식 터미널의 선폭이 구식 인쇄 규칙에서 비롯된 것이라고 생각합니다.

오른쪽 여백 옵션은 코드를 인쇄하려는 경우 페이지 너비를 표시하기 위해 만들어졌으며 이전에 게시 한 바에 따르면 줄 길이는 GUI 이전에 펀치로 돌아 가기 전에 줄 길이였습니다. 카드.

코드 품질을 향상시키기 위해 IDE 글꼴 크기를 늘리는 최근 일부 블로그에서 (블로그를 기억할 수 없음) 권장 사항을 보았습니다. 배후의 논리는 화면에 코드가 적 으면 더 짧은 줄을 쓰고 shouter 기능.

내 의견으로는 짧은 줄로 코드를 읽고 쉽게 디버깅 할 수 있으므로 줄을 짧게 유지하려고합니다. 더 나은 코드를 작성하도록 제한을 설정 한 다음 자신에게 적합한 것을 선택하십시오-생산성이 더 높은 경우에도 줄이 길어지면 넓은 화면에서만 페이지 크기와 코드를 자유롭게 늘릴 수 있습니다.

어떤 사람들은 다른 답변에서 80 자 제한의 이유는 부분적으로 역사적이며 (펀치 카드, 작은 화면, 프린터 등) 부분적으로 생물학적입니다 (일부 줄을 추적하는 것이 일반적으로 전체 줄을 보는 것이 좋습니다) 머리를 돌리지 않아도됩니다).

즉, 우리는 여전히 인간이며 우리 자신의 한계를 해결할 수있는 도구를 개발합니다. 문자 제한에 대한 전체 토론을 무시하고 길이에 관계없이 의미있는 내용을 작성하고 IDE 또는 텍스트 편집기를 사용하여 줄을 올바르게 추적하는 데 도움을 줄 것을 제안합니다. 탭 대 공백 토론에서 들여 쓰기에 동일한 인수를 사용하고 들여 쓰기의 너비를 들여 쓰기 할 수있는 방법 들여 쓰기 표식 (가장 일반적으로 탭)을 사용하고 사람들이 자신의 IDE 또는 텍스트 편집기를 구성하여 표시하도록 제안하십시오 그들은 그들에게 가장 편안하다고 생각합니다.

한 줄에 고정 된 수의 문자를 고수하면 대상 독자 이외의 모든 사람에게 항상 상황이 악화됩니다. 즉, 코드를 절대 공유하지 않을 것입니다. 이 토론을 시작해야 할 이유가 없습니다. 코드를 공유하고 싶다면 사람들이 자신에게 이상적인 것을 강요하는 대신 원하는 것을 스스로 결정하도록해야합니다.

내가 아는 한 80 자 문자는 명령 줄 편집기와의 호환성을 유지하기위한 코딩 표준으로 사용됩니다 (기본 터미널 너비는 일반적으로 80 자임). 최신 IDE와 큰 화면 해상도를 사용하면 80자가 "최적"이 아닐 수 있지만 많은 개발자에게는 터미널에서 가독성을 유지하는 것이 필수적입니다. 이러한 이유로 80 자 너비가 곧 코드 너비의 사실상 표준으로 대체 될 가능성은 없습니다. 마지막 질문에 대답하려면 코드 너비뿐만 아니라 코드의 가독성에 영향을 줄 수있는 다른 특성도 코딩 표준에서 다루어야합니다.