최적의 코드 너비에 대한 연구?
선택한 IDE에서 "오른쪽 여백보기"를 활성화하면 기본적으로 80 자로 설정 될 수 있습니다. 몇 년 전 회사의 표준이었던 것 외에는 아무 이유없이 120으로 바꾸는 경향이 있으며, 다른 회사에서는 다르게 말하지 않았습니다.
제 질문은 코드 판독성을 위해 최적의 최대 너비로 80자를 실제로 보여주는 연구가 있습니까, 아니면이 값이 "항상 그랬던 것"이고 왜 그런지 아무도 모르는 사람일까요? 코드 줄의 너비가 코딩 표준의 일부 여야합니까?
실제로, 80 열이 DOS보다 오래갑니다. 그것은 80 열 장치 인 카드 펀치에서 나옵니다.
그리고 OP의 질문에 대한 답을 얻기 위해, 한 "연구"는 현재 약 600 년 동안 진행되어 왔습니다 – 인쇄 된 책. 텍스트의 평균 줄 길이가 약 60자인 현재 위치로 수 세기 동안 가독성을 염두에두고 발전했습니다. 따라서 가독성을 높이려면 여백을 좁히십시오.
나중에 소프트웨어를 유지 관리하고 80 자 제한을 유지해야하는 프로그래머에게 자비를 베푸십시오.
80을 선호하는 이유 :
랩톱에서 더 큰 글꼴로 읽을 수 있음
비교를 위해 두 버전을 나란히 놓을 공간을 남겨 둡니다.
IDE에서 탐색 뷰를위한 공간 확보
임의로 줄을 바꾸지 않고 인쇄합니다 (이메일, 웹 페이지에도 적용됨).
한 줄로 복잡성을 제한합니다
들여 쓰기를 제한하여 결과적으로 메소드 / 기능의 복잡성을 제한합니다
예, 코딩 표준의 일부 여야합니다.
나는 공부를하지 않지만 내 경험을 이야기 할 것입니다.
텍스트를 다룰 때 가로 스크롤이 지루 하다는 것을 알았습니다 . 코드가 사용될 환경을 살펴보고 해당 컨텍스트를 기반으로 너비 표준을 설정합니다.
예를 들어, XWindows의 Emacs에서 일할 때 항상 2 개의 Emacs 창이 나란히 있는 것이 좋습니다. 그것은 80 자로 제한되었으므로 최대 줄 길이였습니다.
어느 시점에서 나는 Visual Studio에서 1920x1200 화면에서 일했습니다. 모든 도구 창이 한쪽에 도킹되어 최대화되어 있습니다. 두 개의 편집기 창에 약 100 자씩 나란히 충분한 공간이 남아있었습니다.
또한 가장 긴 행은 매개 변수 목록이 긴 메소드 호출 에서 나온다는 것을 알았습니다 . 이것은 때때로 코드 냄새입니다 . 아마도 메소드를 리팩터링 해야합니다 .
나와 프로그래머가 고해상도 화면과 선명한 시력을 가지고 있다면 반드시 작은 글꼴과 긴 줄을 사용하십시오. 반대로 짧은 줄이 필요할 수 있습니다.
회사에서 달리 설명하지 않는 한 일반적으로 120-150을 사용합니다. 그러나 그것은 또한 코드의 종류에 달려 있습니다 :
- 나는 (거의) 한 줄에 여러 문장을 사용하지 않습니다
- 비슷한 줄이 정렬되고 끊어지지 않는 경우에만 긴 줄 (> 12) 만 사용합니다.
- 나는 항상 충분한 공간 / 괄호 등을 사용합니다
- 짧은 이름보다 긴 변수 이름을 선호합니다
몇 년 전까지는 100 개로 제한되었지만 이제는 와이드 스크린이 일반적으로 사용되고 고해상도 모니터 (120)는 랩톱에서도 볼 수 있습니다.
책에 더 많은 수직 공간이 있고 화면에 더 많은 수평 공간이 있기 때문에 화면을 책과 비교하는 것은 실제로 좋지 않습니다. 나는 항상 기능을 최대로 유지하려고합니다. 하나의 보이는 화면.
어쩌면 80 문자가 나쁜 게터 체인을 피하기에 좋은 지적 일 수도 있습니다.
object.getFoo().getBar().getFooBar().get ...
80 자로 제한하면 누군가가 이러한 변수를 지역화하고 null 검사 등을 수행하지만 대부분의 프로그래머는 다음 행에서 줄 바꿈 할 수 있습니다. 모르겠다
그 외에도 스타 블루가 언급 한 것처럼 80자가 좋습니다. 이것은 코딩 표준에 방어 적으로 적용되어야합니다.
하드웨어 제한과 코드와 자연어를 읽는 방식의 차이점을 무시하면서 줄을 약 80 자로 제한해야하는 세 가지 주요 이유가 있습니다.
- 인간의 안구는 둥글고 좁고 넓지 않으며 대부분의 해상도가 중간에 있습니다. 한 번에 몇 시간 동안 읽을 때 필요에 따라 하나의 스크롤 막대를 사용하여 짧은 원호로 눈을 쓸어주는 것이 훨씬 편안합니다. 코드의 가독성에 대한 공식적인 연구는 알지 못하지만, 모니터에서 2 피트 떨어져 있고 텍스트가 10pt 고정 폭 글꼴 크기 인 100 자 (영문)는 가로 필드의 약 1/3을 차지합니다. 시력, 또는 약 60도 ( 우리의 모든 눈의 해상도가 30도를 벗어난 정도 ).
- 대부분의 사람들은 직장에서 큰 모니터를 사용하므로 한 번만 클릭해도 큰 화면을 볼 수 있도록 앞뒤로 클릭하지 않고도 여러 항목을 볼 수 있습니다.
- 줄이 짧을수록 복잡성이 줄어들 기 때문에 개발자가 코드를 더 소화 가능한 단위로 분해해야합니다.
나는 최적의 가독성을 위해 문서의 너비가 약 2 개의 알파벳 또는 60-70 자 여야한다는 어딘가에서 읽은 것을 분명히 기억합니다 ( Agile Documentation 에 있다고 생각합니다 ). 나는 구식 터미널의 선폭이 구식 인쇄 규칙에서 비롯된 것이라고 생각합니다.
오른쪽 여백 옵션은 코드를 인쇄하려는 경우 페이지 너비를 표시하기 위해 만들어졌으며 이전에 게시 한 것으로 80으로 설정되었다고 말 했으므로 GUI 이전의 줄 길이는 펀치에 이르기까지 카드.
코드 품질을 향상시키기 위해 IDE 글꼴 크기를 늘리는 최근 일부 블로그에서 (블로그를 기억할 수 없음) 권장 사항을 보았습니다. 배후의 논리는 화면에 코드가 적 으면 더 짧은 줄을 쓰고 shouter 기능.
내 의견으로는 짧은 줄로 코드를 읽고 쉽게 디버깅 할 수 있으므로 줄을 짧게 유지하려고합니다. 더 나은 코드를 작성하도록 제한을 설정 한 다음 자신에게 적합한 것을 선택하십시오-생산성이 더 높은 경우에도 줄이 길어지면 넓은 화면에서만 페이지 크기와 코드를 자유롭게 늘릴 수 있습니다.
어떤 사람들은 다른 답변에서 80 자 제한의 이유는 부분적으로 역사적이며 (펀치 카드, 작은 화면, 프린터 등) 부분적으로 생물학적입니다 (일부 줄을 추적하는 것이 일반적으로 전체 줄을 보는 것이 좋습니다) 머리를 돌리지 않아도됩니다).
That said, please remember that we are still humans and we build tools to solve our own limitations. I propose you ignore the entire debate about character limitation and just write stuff that makes sense regardless of their length, and use an IDE or text editor that can help you keep track of the lines properly. Using the same argument for indentation in the tabs vs spaces debate, as well as the how wide should the indentations be I propose you use an indentation marker (most commonly the tab) and just have people configure their own IDE or text editors to display them as they find most comfortable to them.
Sticking with a fixed number of characters per line will always make things worse for everyone but the targeted audience. That said, if you will never share the code, ever; then there's really no reason to even have this discussion to begin with. Should you want to share the code, you should probably let people decide what they want on their own instead of forcing yours (or someone elses) ideals on them.
To the best of my knowledge the 80 character is used as a coding standard to maintain compatibility with command line editors (default terminal width is typically 80 characters). With modern IDEs and large screen resolutions 80 characters is probably not "optimal", but for many developers maintaining readability in the terminal is essential. For that reason it is not likely that 80 character width will be replaced as the de facto standard for code width anytime soon. And to answer your final question, yes, code width as well as any other characteristic which will affect your code's readability should be addressed in your coding standards.
참고URL : https://stackoverflow.com/questions/578059/studies-on-optimal-code-width
'programing tip' 카테고리의 다른 글
값이 null 인 맵 항목을 무시하는 Gson (0) | 2020.07.12 |
---|---|
고스트 이미지의 드래그를 방지하는 CSS / JS? (0) | 2020.07.12 |
WPF의 키보드 단축키 (0) | 2020.07.12 |
패브릭 작업에 매개 변수 전달 (0) | 2020.07.11 |
리턴하기 위해 오브젝트를 일반 유형으로 캐스트 (0) | 2020.07.11 |