PEP-8이 최대 줄 길이를 79 자로 지정하는 이유는 무엇입니까? [닫은]


235

왜이 밀레니엄에서 파이썬 PEP-8최대 줄 길이를 지정 해야합니까? 79 자 를 합니까?

태양 아래있는 거의 모든 코드 편집기는 더 긴 줄을 처리 할 수 ​​있습니다. 줄 바꿈으로 수행 할 작업은 콘텐츠 제작자의 책임이 아니라 콘텐츠 소비자의 선택이어야합니다.

이 연령대에 79자를 고수해야 할 정당한 이유가 있습니까?


73
귀하의 질문에 대한 대답은 PEP-8.
cdleary

29
줄 길이가 짧으면 KLOC가 증가하여 생산성이 향상됩니다. : p
Alex

26
79 자 제한이 완전히 구식입니다. 적당히 복잡한 코드베이스는 코드를 훨씬 더 어색하게 읽는 방법을 보여줍니다. 예 : github.com/openstack/nova/blob/master/nova/network/manager.py
Jonathan


9
사람들이 나란히 다른 도구를 사용하지 않습니까?
endolith

답변:


129

PEP-8의 가치 중 상당수는 사람들이 결과가 아닌 형식 규칙에 대해 논쟁하는 것을 막고 일관되고 형식이 좋은 코드를 작성하는 것입니다. 물론, 79가 최적이라고 생각하는 사람은 없지만 99 나 119로 바꾸거나 원하는 선 길이가 무엇이든 분명한 이득은 없습니다. 선택 사항은 다음과 같습니다. 규칙을 따르고 싸울만한 가치있는 원인을 찾거나 줄 길이에 따라 가독성과 생산성이 어떻게 다른지 보여주는 데이터를 제공하십시오. 후자는 매우 흥미로울 것이며 내가 생각하는 사람들의 마음을 바꿀 수있는 좋은 기회가 될 것입니다.


28
대부분의 읽기 연구는 한 줄에 문자가 아닌 인치 단위로 수행됩니다. 66 자 규칙은 신문을 읽기 위해 수행 된 연구를 기반으로합니다. 최근의 연구 에 따르면 온라인 기사를 읽을 때 독해력을 잃지 않으면 서 한 줄에 최대 120 자 (12 글자에서 10 인치)까지 읽기 속도가 증가하는 것으로 나타났습니다.
Pace

7
실제로이 주제를 읽는 모든 사람 은 79자가 최적 이라고 생각 합니다. 이것이 PEP8에 추가 된 이유입니다! 이 답변은 실제로 잘못되었습니다. 이것은 올바른 것입니다
erikbwork

6
나는 질문 79 더 80 또는 78 인 이유에 관한 생각
n611x007

157
there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is 이것은 여러 가지면에서 너무 잘못되었습니다. 40자를 한 줄로 감싸서 읽을 수있는 정도를 알려주십시오. 2015 년에는 화면 공간이있는 한 줄 바꿈이 적을수록 가독성이 높아집니다. 랩핑은 가독성에 영향을줍니다. 가독성은 유지 보수성에 영향을줍니다. 유지 보수성은 품질에 영향을줍니다. 80 자로 줄 바꿈하면 품질에 영향을 미칩니다. 마침표.
Jonathan

6
코드가 아닌 것을 가진 가독성에 대한 논쟁은 그러한 연구가 텍스트를 실행한다고 가정 할 때 쓸모가 없습니다. 코드는 한 줄마다 다른 (문자) 줄 길이로 완전히 다르게 보입니다. 줄 끝까지 쓰더라도 들여 쓰기는 줄당 문자 수를 변경합니다.
Corvince

111

기계가 읽을 수있는 것이 아니라 사람이 읽을 수있는 코드를 유지하십시오. 많은 장치가 한 번에 80 자만 표시 할 수 있습니다. 또한 큰 창을 가진 사람들이 여러 창을 나란히 설정할 수있어 멀티 태스킹이 더 쉬워집니다.

가독성은 또한 줄 들여 쓰기를 강제하는 이유 중 하나입니다.


58
그렇습니다. 그런데 왜 79? 왜 100이나 120이 아닌가? 읽을 수있는 상태를 유지하면 두 가지 방식으로 작동합니다. 코드를 너무 많이 위아래로 읽는 것도 어렵습니다.
pcorcoran

17
많은 장치가 80 자만 표시 할 수 있다는 것은 사실입니다. 소프트 랩핑을 할 수없는 사람은 몇 명입니까?
Jim

39
또한 코드 랩을 사용하지 않는 것이 좋습니다. 사용자 경험의 관점에서 볼 때 대부분 받아 들일 수 없습니다.
Justin Bozonier

8
MVS와 같은 일부 운영 체제에는 72 자보다 긴 행을 처리 할 수 ​​없습니다. PEP-8은 여기서 도움이되지 않습니다. 한 줄에 문자가 얼마나 좋은지 편집기, 모니터, 사용자의 개인 취향 등에 따라 달라 지므로 임의의 한도 인 79자를 설정하는 것은 의미가 없습니다.
codymanix

96
또한 79자를 사용하면 프로그래머가 더 짧은 암호 변수 및 함수 이름을 사용하여 모든 것을 적합하게 만듭니다. 가독성이 좋지 않습니다.
Gert Steyn

46

나는 매일 많은 코드를 다루어야하는 프로그래머입니다. 오픈 소스와 사내에서 개발 된 것.

프로그래머로서 많은 소스 파일을 한 번에 열어 두는 것이 좋으며, 두 개의 소스 파일이 나란히되도록 (와이드 스크린) 모니터에서 데스크탑을 구성하는 경우가 많습니다. 둘 다 프로그래밍하거나 하나를 읽고 다른 프로그래밍을 할 수 있습니다.

해당 소스 파일 중 하나의 너비가 120자를 초과 할 경우 불만족스럽고 좌절감을 느낍니다. 왜냐하면 한 줄의 코드로 코드를 편안하게 맞출 수 없기 때문입니다. 줄 바꿈으로 서식을 화나게합니다.

나는 '120'이라고 말합니다. 왜냐하면 그것이 코드가 더 넓을 때 짜증이 날 것입니다. 그 후 많은 문자를 사용하면 코딩 표준은 물론 가독성을 위해 여러 줄로 분할해야합니다.

80 개의 열을 염두에두고 코드를 작성합니다. 이것은 그 경계를 넘어 누수 할 때 그렇게 나쁜 것이 아닙니다.


11
"저는 80 개의 열을 염두에두고 코드를 작성합니다.이 경계를 넘어 누수 할 때 그렇게 나쁜 것은 아닙니다." 저도 마찬가지입니다.
KobeJohn

4
10 년 후 : 줄 바꿈 설정 방법에 따라 달라지지는 않습니다. 줄 바꿈은 원하는만큼 지능적이거나 어리 석습니다. 읽는 것이 불편하다면 그것은 에디터의 실패 일뿐입니다.
David Mulder

2
나는 120 자로 코딩하지만 가독성에 맞을 때 더 길다. 당신이 그것을 말하면 120에서 블랙 포맷. PEP-8은 또한 "길이 제한을 99 자까지 늘려도 괜찮다"고 말하지만 사람들은 그 정보를 많은 시간 동안 억제하고있는 것 같습니다. 거의 80 폭의 터미널을 사용하는 사람은 거의 없습니다. 로그 메시지의 너비는 80입니다.
NeilG

37

타이포그래피를 연구하는 사람들은 줄 당 66 문자가 가장 읽기 쉬운 길이라고 가정 할 것입니다. 그럼에도 불구하고 ssh 세션을 통해 원격으로 머신을 디버깅해야하는 경우 대부분의 터미널은 기본적으로 80 자 (79 자)로 적합합니다. 또한 vim + screen을 일상 환경으로 사용하는 개발자 수에 놀라게 될 것입니다.


<flame> Emacs FTW! </ flame> +1입니다. 나는 79x 제한이 80x25 문자 터미널을 가진 UNIX의 초기 (그리고 아마도 MULTICS)에서 나온 것이라고 생각합니다.
Joe D

10
내 ssh + screen + vim 환경은 긴 줄을 표시하는 데 아무런 문제가 없습니다.
chrishiestand

54
"한 줄에 66 자 길이는 가장 읽기 쉬운 길이 여야합니다."신문이 배치되는 방식이므로 2 열 또는 3 열로 코드를 작성해야한다고 가정합니다.
Mark E. Haase

23
@mehaase : 당신의 냉소적 인 말은 진실에 아주 가깝습니다. 괜찮은 편집자들은 분할 창을 나눌 수 있고 (동일하거나 다른 파일에서) 다른 것들을 나란히 표시 할 수 있습니다. 우연히도, 이것은 일반적으로 코드의 길이가 표준
nperson325681

2
@ mehaase : 사실 굉장히 들립니다. 농담이 아냐.
Teekin

19

기본 크기로 고정 폭 글꼴을 인쇄하는 것은 (A4 용지에서) 80 열 x 66 행입니다.


11
나는이 표준을 받아들입니다. 유효합니다. 그러나 누가 더 이상 코드를 인쇄합니까? 또한 스케일링이나 다른 형식 지정 옵션을 견딜 수없는 환경에서 누가 코드를 인쇄합니까? 마지막으로 100자를 한 줄로 렌더링 할 수 없다는 사실을 알고있는 사람은 언제입니까?
pcorcoran

3
사람들이 2012 년에 코드를 인쇄하는 이유는 무엇입니까? 테크놀로지 컨퍼런스에 참석하여 프리젠 테이션이 가득한 가방과 인쇄 된 바인더를 건네주었습니다. 21 세기 사람들입니다. 슬라이드 나 다른 가방과 바인더가 매립지로 곧바로 이동한다는 이메일을 보내주십시오.
Mark E. Haase

2
그렇다면 80-1이 80-0 또는 80-2보다 나은 이유는 무엇입니까?
n611x007

11
"기본 크기로"당신이 말하는가? 보편적으로 허용되는 기본 크기에 대해 자세히 알려주세요.
Bruno Bronosky

15
그렇습니다. 인쇄 된 용지에서 코드가 보이는 방식에 우선 순위를 두겠습니다.
Jonathan

8

80 문자를 좋아하는 이유는 다음과 같습니다. 직장에서 Vim을 사용하고 1680x1040에서 실행되는 모니터에서 한 번에 두 파일을 작업합니다 (생각할 수 없습니다). 줄이 더 이상 줄 바꿈을 사용하는 경우에도 파일을 읽는 데 문제가 있습니다. 말할 것도없이, 나는 다른 사람들이 긴 줄을 좋아할 때 코드를 다루는 것을 싫어합니다.


javascript / html에 vim을 사용하지 않습니까?
elad silver

2
@eladsilver 농담이라면 해결할 수 없습니까? :-D
Steven Church

죄송합니다, vim에 심오하지 않습니다. 분명히 웹에서 작업하는 경우 html / js에도 사용하고 프런트 엔드 개발자는 pep8에 대해 알지 못하므로 해당 유형에는 80 자 제한이 없으므로 python limit 80-char 파이썬 이상을 사용하면 문제가 해결되지 않습니다. 그래서 내가 묻는 것은 다른 코딩 언어를 어떻게 처리합니까?
elad silver

120 문자 줄로 Vim에서 일합니다. 가로 분할과 함께 : diffthis를 사용합니다. 1680 픽셀에 160 자만 사용할 수있는 경우 큰 글꼴 크기가 있어야합니다.
NeilG

4

공백은 파이썬에서 의미 론적 의미를 갖기 때문에 일부 단어 줄 바꿈 방법은 부정확하거나 모호한 결과를 생성 할 수 있으므로 이러한 상황을 피하기 위해 약간의 제한이 필요합니다. 텔레타이프를 사용한 이후 80 자 길이의 문자가 표준 이었으므로 79 자 정도의 문자가 안전한 선택 인 것 같습니다.


4
두 가지 유형의 단어 줄 바꿈이 있습니다. 줄 바꾸기는 줄 바꿈으로 구분되고 줄 바꿈은 줄 바꿈만으로 표시 되지만 실제로는 줄 한 줄로 표시됩니다 . 후자에는 아무런 문제가 없습니다.
Jim

4
대부분의 Python 편집기는 공백과 들여 쓰기가 중요한 언어로 코드를 읽기가 어렵 기 때문에 소프트 단어 줄 바꿈을 사용하지 않습니다.
Chris Upchurch

4
래핑이 시각적으로 식별되는 한 모호하거나 읽기 어려운 코드는 생성하지 않습니다. 케이트가 이것을하고 잘 작동합니다. 에디터가 이것을 처리하지 않는다면, 버그를 피하는 코딩 스타일을 강요하는 것이 아니라 에디터에 버그를 제기하는 이유입니다.
Jim

5
시각적으로 표시되어 있어도 코드를 읽기가 더 어려워 지므로 일반적으로 Python 편집기는이를 지원하지 않습니다.
Chris Upchurch 2018 년

실제로 오랫동안 사용해 보셨습니까? 나는 가지고있다. 내 경험에서 코드를 읽기가 더 어렵지 않습니다. 이것이 파이썬 에디터가이 기능을 포함하지 않는 이유라는 주장을 뒷받침 할 수 있습니까? 나는 그 주장을 들어 본 적이 없다.
Jim

1

저스틴에 동의합니다. 보다 정교하게 말하면 사람이 너무 긴 코드 줄을 읽기가 더 어려우며 일부 사람은 한 줄에 80 자만 수용 할 수있는 콘솔 너비를 가질 수 있습니다.

스타일 권장 사항은 가능한 많은 플랫폼에서 가능한 한 편안하고 가능한 한 많은 사람들이 작성한 코드를 읽을 수 있도록하기위한 것입니다.


10
이것은 게으른 논쟁이다. 항상 80 줄이 가독성을 해치는 것은 아닙니다. 80 줄로 감싸는 적당히 복잡한 파이썬 코드베이스를 간단히 살펴보면 실제로는 그 반대가됩니다. 단선 함수 호출을 여러 줄로 줄 바꿈하면 WTF를 따르기가 더 어려워집니다.
Jonathan

0

80 열 이상으로 밀어 넣으면 너무 길고 복잡한 코드 줄을 작성하고 있거나 리팩터링해야하거나 너무 많이 들여 쓰기해야하므로 리팩토링해야한다는 것을 의미합니다.


90
-1, 80 문자 경계를 지나는 행에는 리 팩터가 필요하다고 범주 적으로 말할 수 있다고 생각하지 않습니다. 클래스 메소드는 이미 두 번 들여 쓰기되어 있고, "if"등에 대한 또 다른 들여 쓰기를 추가하고 간단한 목록 이해를 제공하며, 80 자 경계를 넘어가는 것은 매우 쉽습니다.

42
말할 것도없이, "usr_dir_gph"대신 "users_directed_graph"와 같이 사람이 읽을 수있는 방식으로 기호의 이름을 지정하면 간단한 표현조차도 한 줄에 많은 문자를 먹습니다.
Mark E. Haase

8
나는 항상 파이썬에서 80자를 초과하면 그 이유를 생각하고 멈추는 것이 현명하다는 것을 알았습니다. 일반적으로 잘못된 설계 결정에 결함이 있습니다.
Mike Vella

3
이것은 나의 경험이기도합니다. @mehaase가 지적한 것처럼 더 긴 변수 이름도 처리하지만 이것이 이점이라고 생각합니다. 세 개의 연속 단어 ( "users_directed_graph"의 경우)의 사용 가능한 조합은 단일 네임 스페이스에 합리적으로 적합한 구성 요소의 수를 줄입니다. 비슷한 긴 변수 이름이 동일한 네임 스페이스에있는 곳에서 더 읽기 어렵고 일반적으로 리팩토링하는 것이 더 오래된 코드를 생각합니다.
TimClifford

4
범위가 변경 될 때마다 들여 쓰기가 필요한 언어에서 80 개의 문자 행이 복잡성과 동일하다는 것은 지나치게 단순한 주장입니다. 때로는 80 문자가 함수를 호출하는 데 필요한 것입니다. 다른 언어에 대한 최신 IDE / 편집기는이를 인식하기에 충분히 영리하며 전반적으로 가독성에 해를 끼치는 모든 것에 담요 제한을 두는 것과는 반대로 포장해야 할 시점을 식별 할 수 있습니다.
Jonathan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.