为什么PEP-8指定的最大行长为79个字符?[关闭]


235

为什么在这个千年中,Python PEP-8应该指定最大行长度为79个字符?

在阳光下几乎每个代码编辑器都可以处理更长的行。包装应该是内容消费者的选择,而不是内容创建者的责任。

在这个年龄段,是否有(合理的)充分理由坚持使用79个字符?


73
您的问题的答案是 PEP-8中。
cdleary

28
较短的线长通过增加KLOC来提高生产率。:p
亚历克斯

26
79个字符的限制已完全过时。任何适度复杂的代码库都显示了它如何使代码阅读起来更加尴尬。例如:github.com/openstack/nova/blob/master/nova/network/manager.py
Jonathan

6
@Jonathan:对我来说很好...
nperson325681

9
你们不是在使用差异工具吗?
Endolith's

Answers:


129

PEP-8的许多价值在于阻止人们争论无关紧要的格式化规则,并继续编写良好的,一致的格式化代码。当然,没有人真的认为79是最佳选择,但是将其更改为99或119或您首选的行长都没有明显的好处。我认为选择是这样的:遵循规则并找到值得争取的理由,或者提供一些数据来证明可读性和生产率如何随行长而变化。后者将非常有趣,并且我有很大的机会改变人们的想法。


28
大多数阅读研究都是以英寸为单位,而不是以每行字符为单位。66个字符的规则基于对阅读报纸所做的研究。 最近的研究表明,阅读在线文章时,阅读速度每行最多可增加约120个字符(12字体时为10英寸),而不会造成理解力的损失。
佩斯

7
实际上,阅读该主题的每个人都认为 79个字符是最佳的。这就是为什么它被添加到PEP8!这个答案实际上是错误的。这是正确的一个
erikbwork

6
我以为问题是为什么79优于80或78
n611x007 2014年

157
there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is 在很多方面这都是错误的。用40个字符换行,然后告诉我它的可读性。显然,只要您有屏幕空间,更少的包装=更高的可读性(2015年就可以做到)。包装会影响可读性。可读性影响可维护性。可维护性影响质量。如果包装80个字符,则会影响质量。句号
乔纳森·

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 2013年

46

我是一个程序员,每天必须处理大量代码。开源以及内部开发的东西。

作为一名程序员,我发现一次打开多个源文件很有用,并且经常在(宽屏)监视器上组织桌面,以便两个源文件并排。我可能两者都在编程,或者只是阅读其中一项,而另一种则在编程。

当这些源文件之一的宽度大于120个字符时,我会感到不满意和沮丧,因为这意味着我无法舒适地将一行代码放在屏幕上。它将格式设置换行。

我之所以说“ 120”,是因为这会导致我对超出范围的代码感到恼火。在输入了这么多字符之后,您应该为了便于阅读而将行分开,更不用说编码标准了。

我在编写代码时会考虑80列。只是这样,当我确实在该边界上泄漏时,这并不是一件坏事。


11
“我在编写代码时会考虑80列。这只是当我确实在该边界上泄漏时,这并不是一件坏事。” 我也是。
科比·约翰

4
10年后:这不仅仅取决于您如何设置换行。换行可以根据需要灵活或愚蠢。如果阅读不舒服,那只是编辑器的故障。
大卫·穆尔德

2
我编码为120个字符,但在适合可读性时偶尔会更长。如果您告诉的话,黑色格式为120。PEP-8还说“可以将行长度限制增加到99个字符是可以的”,但是人们似乎在很多时候都抑制了该信息。几乎没有人使用80宽的终端。日志消息永远不会超过80。
NeilG

37

我相信那些研究版式的人会告诉您,每行66个字符应该是长度上最易读的宽度。即使这样,如果您需要通过ssh会话远程调试机器,大多数终端默认为80个字符,而79个恰好适合,在这种情况下尝试使用任何更宽的设备将是一个真正的痛苦。使用vim +屏幕作为日常环境的开发人员数量也将令您感到惊讶。


不过,<flame> Emacs FTW!</ flame> +1。我认为79的限制来自拥有80x25字符终端的UNIX(可能还有MULTICS)的早期。
乔D

10
我的ssh + screen + vim环境显示长行没有问题。
chrishiestand

54
“每行66个字符应该是长度上最易读的宽度”我想我们应该在2或3列中编写代码,因为那是报纸的布局方式?
Mark E. Haase 2012年

23
@mehaase:您的讽刺话非常接近事实:体面的编辑者可以拆分窗格并并排显示不同的内容(来自相同或不同的文件)。巧合的是,这通常仅在代码具有
行长

2
@mehaase:听起来真棒。我不是在开玩笑。
Teekin

19

在A4纸上,默认尺寸下的等宽字体打印为80列乘66行。


11
我接受这个标准;是有效的 但是谁再打印代码呢?此外,谁从无法缩放或其他格式设置选项的环境中打印代码?您认识的人最后一次是因为无法渲染100个字符的行而感到困惑吗?
pcorcoran

3
人们为什么在2012年打印代码?这让我想起了参加技术会议并被递到一个装满演示文稿的书包和印刷活页夹的过程。这是21世纪的人们:给我发送幻灯片的幻灯片,否则,袋子和活页夹将直接进入垃圾填埋场。
Mark E. Haase 2012年

2
那么为什么80-1优于80-0或80-2?
n611x007 2014年

11
“默认大小”您说?告诉我更多有关这些普遍接受的默认大小的信息。
布鲁诺·布鲁诺斯基

15
是的,首先让我们优先考虑代码在打印纸上的显示方式。
乔纳森·

8

这就是为什么我喜欢80个字符的原因:在工作中,我使用Vim,并在运行于1680x1040的监视器上一次处理两个文件(我不记得了)。如果行数不再长,即使使用自动换行,我也很难读取文件。不用说,我讨厌处理别人的代码,因为他们喜欢排长队。


您不是也将vim用于javascript / html吗?
埃拉德·银

2
@eladsilver如果那是个玩笑,我无法解决?:-D
史蒂文·丘奇

抱歉,对vim不太了解,很显然,如果您在Web上工作,也将它用于html / js,并且这些类型永远不会限制80个字符,因为前端开发人员不了解pep8,因此使python限制为80个字符如果仅使用python,将无法解决您的问题。所以我要问的是您如何处理其他编码语言?
埃拉德·银

我在Vim中使用120个字符行。我用:diffthis与水平分割。如果只能在1680像素上容纳160个字符,则必须使用较大的字体。
NeilG,

4

由于空格在Python中具有语义含义,因此某些自动换行方法可能会产生不正确或模棱两可的结果,因此需要有一定的限制以避免这些情况。自从我们使用电传打字机以来,标准的行长为80个字符,因此79个字符似乎是一个非常安全的选择。


4
有两种不同类型的自动换行。有硬包装,其中的行用换行符分隔,有软包装,其中的行仅用中断显示,但实际上保持为单行。我认为后者没有任何问题。
吉姆(Jim)

4
大多数Python编辑器都不会进行软自动换行,因为它会产生用空格和缩进很重要的语言来产生难以理解的模棱两可的代码。
克里斯·厄普彻奇

4
只要包装以某种方式在视觉上被识别,它就不会产生歧义或难以阅读的代码。凯特(Kate)做到了,而且效果很好。如果编辑器不处理此问题,那么这就是向编辑器提交错误的原因,而不是强加以避免该错误的编码样式的原因。
吉姆(Jim)

5
即使以视觉方式进行指示,它仍然使代码更难阅读,这就是Python编辑器通常不支持它的原因。
克里斯·厄普彻奇

您实际上已经尝试了很长时间吗?我有。根据我的经验,这并不会使代码更难阅读。您是否可以支持Python编辑器不包含该功能的原因?我以前从未听说过这种说法。
吉姆

1

我同意贾斯汀。详细来说,人很难阅读过长的代码行,并且某些人的控制台宽度每行只能容纳80个字符。

推荐使用样式,以确保尽可能多的人在尽可能多的平台上尽可能舒适地阅读您编写的代码。


10
这是一个懒惰的论点。80行并不总是会损害可读性。快速浏览一下包装有80行的任何适度复杂的Python代码库,实际上显示了相反的事实-将单行函数调用包装到多行使得执行WTF变得更加困难。
乔纳森

0

因为如果将其推到第80列之外,则意味着您正在编写的代码行很长且很复杂,执行了太多操作(因此您应该重构),或者缩进太多了(因此您应该重构)。


90
-1,我认为您不能明确地说超过80个字符边界的任何行都需要重构。类方法已经缩进两次,为“ if”等添加另一个缩进,以及一个简单的列表理解,并且跨越80个字符的界限非常容易。

42
更不用说如果您以易于理解的方式命名符号,例如用“ users_directed_graph”而不是“ usr_dir_gph”命名,那么即使是一个简单的表达式也将占用每行很多字符。
Mark E. Haase 2012年

8
我一直在Python中发现,如果我超过80个字符,明智的做法是停止并思考为什么这样做。通常,错误的设计决策是错误的。
Mike Vella

3
这也是我的经验。正如@mehaase所指出的,它也处理更长的变量名,但是我认为这是有好处的。三个连续单词的可用组合(在“ users_directed_graph”的情况下)使合理地适合单个命名空间的组件数量相形见war。我认为我编写的较旧的代码在同一名称空间中存在许多相似的长变量名称,这些名称较难阅读,并且通常更易于重构。
TimClifford 2014年

4
在一种要求缩进范围的语言中,说80个字符行等同于复杂性是一个过于简单的论点。有时,仅80个字符就是调用一个函数所需要的。用于其他语言的现代IDE /编辑器足够聪明,可以识别这一点,并且可以识别何时包装,而不是对所有会损害可读性的内容进行全面限制。
乔纳森
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.