为什么PEP-8指定的最大行长度为79个字符？

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

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

在这个时代,有没有(合法的)充分理由坚持79个角色？

1> 小智..：

---

PEP-8的大部分价值在于阻止人们争论无关紧要的格式规则,并继续编写良好的,格式一致的代码.当然,没有人真的认为79是最佳的,但是将它改为99或119或者你喜欢的线路长度没有明显的好处.我认为选择是这样的:遵循规则并找到值得争取的原因,或者提供一些数据来说明可读性和生产率如何随着线路长度而变化.后者将非常有趣,并且很有可能改变人们的想法.

---

`将它改为99或119,或者无论你喜欢什么样的线长,都没有明显的好处.这在很多方面都是错误的.用40个字符包裹一行,并告诉我它的可读性.显然减少包装=更多的可读性,只要你有屏幕空间,在2015年,你做.包装会影响可读性.可读性会影响可维护性.可维护性会影响质量.如果你用80个字符包裹,质量就会受到影响.完全停止.

---

大多数阅读研究以英寸而非每行字符完成.66个字符规则基于阅读报纸的研究.[最新研究](http://www.usability.gov/articles/newsletter/pubs/082006news.html)显示,在阅读在线文章时,阅读速度每行增加约120个字符(12英寸大小为10英寸) )没有理解上的损失.

---

实际上,阅读该主题的每个人都认为*79个字符是最佳的.这就是它被添加到PEP8的原因!这个答案实际上是错误的.[这是正确的](http://stackoverflow.com/a/88948/131120)

---

任何非代码的可读性都是无用的,因为这些研究假定运行文本.代码看起来完全不同,每行的不同(字符)行长度.即使你写到行的末尾,缩进也会改变每行的字符数.

---

我认为问题在于为什么79优于80或78

---

我遇到的最大问题是，与几乎所有我认识的程序员一样，我使用同一终端来编辑代码和运行代码。如果将终端设置为80英寸宽，以便在监视器上留有其他空间，则在运行代码时，堆栈跟踪和日志文件将不可读。这会导致您使用更宽的终端。因此，您的文本编辑器浪费了空间。为什么不使用单独的端子？有时我们会这样做，但对于95％的情况，最好使用“内部不带1 tmux的1个终端窗口”。

---

PEP-8还说“可以将行长限制增加到99个字符是可以的” **，但是人们似乎在很多时候都抑制了该信息。

---

在许多方面这都是错误的。用40个字符换行，然后告诉我它的可读性。显然，只要您有屏幕空间，更少的包装=更高的可读性...如果包装80个字符，则质量会受到影响。句号。`不要太戏剧化。这可能完全是一种错误。另外，您在没有提供任何证据的情况下会充满信​​心地提出强烈要求。我还可以声称，即使您有屏幕空间，200或300个字符的行也不易读。句号 ：p

2> Justin Bozon..：

---

保持代码的可读性,而不仅仅是机器可读性.很多设备一次只能显示80个字符.此外,通过能够将多个窗口并排设置,可以使具有更大屏幕的人更容易进行多任务.

可读性也是强制行缩进的原因之一.

---

79个字符也使程序员使用更短的更加神秘的变量和函数名称来使一切都适合.这对可读性不利.

---

是的,被授予.但为什么79？为什么不是100或120？保持可读性是双向的.对代码进行过多的上下阅读也很难理解.

---

此外,最好没有代码换行.从用户体验的角度来看,这对大多数人来说是不可接受的.

---

确实,很多设备只能显示80个字符.有多少人不能进行软包装？

---

有些操作系统如MVS无法处理超过72个字符的行.PEP-8在这里没有帮助.设置任意限制为79个字符是没有意义的,因为每行字符的好坏取决于编辑器,监视器,用户的个人偏好等.

---

79来自点阵打印机,它们每行只打印80个字符.今天我们都坐着16:9比例的显示器,宽度很大,垂直空间有限......我遵循PEP8中除了这个规则之外的所有规则,我相信它应该与现有技术保持一致.

---

@GertSteyn`今天我们都坐着`不要低估在老式学校4:3上没有椅子的架子旁边的ssh编码.

---

@Jonathan我有一个带有大字体的垂直显示器的设置(所以我可以坐得远离显示器)并经常拆分我的编辑器窗口,这样我就可以同时处理多个文件.行长度限制确实提高了我的可读性.

---

值得注意的是,这个答案在2015年已经过时,甚至我的手机也有足够的分辨率来读取超过80个字符的代码行.

---

这应该是明显的答案

---

老实说，如果您的设备只能显示79列，请购买新的列。现在已经不是80年代了，并且阻碍了每个人，因为有些人自愿决定留在过去是不合理的。字符限制应超出范围大于公司级别（甚至存储库级别）的任何样式指南的OUT。

3> Jerub..：

---

我是一名程序员,每天必须处理大量代码.开源和内部开发的内容.

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

当其中一个源文件的宽度超过120个字符时,我发现它令人不满和令人沮丧,因为这意味着我无法轻松地在一行屏幕上放置一行代码.它将格式化为换行.

我说'120',因为这是我对代码更广泛而烦恼的程度.在那么多字符之后,为了便于阅读,你应该分割线条,更不用说编码标准了.

我编写了80列的代码.这只是为了当我在那个边界上泄漏时,这并不是一件坏事.

---

"我编写了80列的代码.这就是当我泄漏那个边界时,它并不是一件坏事." 我也是.

---

10年后:这不仅仅取决于你如何设置换行.换行可以像你想要的那样聪明或愚蠢.如果读到这只是编辑的失败感到不舒服.

4> Sean O Donne..：

---

我相信那些学习排版的人会告诉你每行66个字符应该是长度最可读的宽度.即便如此,如果你需要通过ssh会话远程调试一台机器,大多数终端默认为80个字符,79只适合,尝试使用更广泛的东西在这种情况下变得真正的痛苦.使用vim + screen作为日常环境的开发人员数量也让您感到惊讶.

---

"每行66个字符应该是长度最可读的宽度"我想我们应该用2或3列编写代码,因为这就是报纸的布局方式？

---

@mehaase:你的讽刺言论非常接近事实:体面的编辑可以做拆分窗格,并排显示不同的东西(来自相同或不同的文件).巧合的是,这通常只有在代码具有行长标准时才可行......

---

我的ssh + screen + vim environemnts显示长行没有问题.

---

@mehaase：听起来真棒。我不是在开玩笑。

5> Josh..：

---

以默认尺寸打印等宽字体是(在A4纸上)80列乘66行.

---

我接受这个标准; 它是有效的.但谁打印代码了？此外,谁从不容忍缩放或其他格式化选项的环境打印代码？什么是你知道的人最后一次被他们无法渲染100个字符的线条感到难过？

---

是的,让我们优先考虑代码在打印纸上看起来的方式.

---

"默认尺寸"你说？告诉我有关这些普遍接受的默认大小的更多信息.

---

为什么人们会在2012年打印代码？这让我想起去参加一个技术会议,并拿着一个袋子和一个印有充分演示文稿的活页夹.这是21世纪的人们:给我发送幻灯片,或者说袋子和活页夹直接进入垃圾填埋场.

6> 小智..：

---

这就是为什么我喜欢80个字符的原因:在工作中我使用Vim并且在运行的监视器上一次处理两个文件,我认为,1680x1040(我永远不会记得).如果行更长,我在阅读文件时遇到问题,即使使用自动换行也是如此.不用说,我讨厌处理其他人的代码,因为他们喜欢长队.

---

@eladsilver如果那是个玩笑，我无法解决？:-D