pep-8“将所有行限制为最多79个字符”的有效性如何。[结束]

我尝试使用它,因为我喜欢有一些惯例来保持我的位置,但我知道动态换行之类的,它变得越来越不常见。例如,linux内核多年来一直将此约定视为一个可靠的规则,但最近,他们已经接受了超过80个字符长的行的贡献。

不是每个人都有25英寸的显示器。我们在这里使用双21英寸显示器设置,但这绝不是标准。还有 许多的 到处 .

these people 不得不说。

在任何语言中,我总是遵循80个字符的限制,原因如下:

• 一致性,一致性,一致性。
• 在多个窗口或列中有多个视图的可能性。
• 在新旧编辑器之间无缝切换。
• 鼓励保持嵌套浅显,论点少,表达简洁。

最后一个是最重要的,它与详细的命名约定轻松地集成在一起。如果它不适合一行或整齐地分成两行,那么不管您的命名,代码可能需要调整无论如何。

虽然我把它称为80个字符的限制,但实际上,对于那些坚持使用滚动条的控制台编辑器来说,最好保持79甚至78列 和 边界。

另一方面,我使用制表符表示缩进,使用空格表示对齐。这样,如果选项卡大小更改,格式就不会受到干扰。不过,关于80列规则,我至少要确保代码在使用4列制表符时不会超出边距,因为制表符大小高于边距的情况并不常见。

• 肩并肩的差异。
• 电子邮件中的代码片段。
• 文本模式控制台(例如,在生产服务器调试期间。)
• GUI编辑器被那些没有最大化每个应用程序来填充桌面的人使用(我个人喜欢把API文档放在屏幕的一边,把编辑器放在另一边。)

尝试将代码保持在一个合理的行长度内以提高可读性是一个好主意。

严格地将代码限制为特定数量的字符,添加额外的换行符(这会损害可读性)只是为了遵守这种任意的限制是不明智的。

短线更容易阅读——这就是为什么大多数书的行长都在60-80个字符之间,而报纸将文本分成多个栏目以保持行长。如果线条太长,那么我认为眼睛会因为从左到右移动而变得紧张,并且在同一条线上会有更多的麻烦。

支持短线。以下几点我没怎么提到:

在版本控制系统(如Perforce)中发生冲突的可能性较小(顺便说一句,这也是按字母顺序排列include语句的一个很好的理由。)

人们在移动设备上查看代码。在iPhone上,您可以轻松地从github读取80个字符的行。较长的行需要z形滚动,这会很快让人讨厌。