我最近开始认为遵循 PEP 8 是一个好主意。我让我的编辑器显示 80 列标记,现在正尝试换行以适应它。我的问题是这个。在 PEP 8 中它说:
将所有行限制为最多 79 个字符。
说得通。
[...] 对于流动的长文本块(文档字符串或注释),建议将长度限制为 72 个字符。
为什么是72?为什么 79 不适用于文档字符串或注释?
我最近开始认为遵循 PEP 8 是一个好主意。我让我的编辑器显示 80 列标记,现在正尝试换行以适应它。我的问题是这个。在 PEP 8 中它说:
将所有行限制为最多 79 个字符。
说得通。
[...] 对于流动的长文本块(文档字符串或注释),建议将长度限制为 72 个字符。
为什么是72?为什么 79 不适用于文档字符串或注释?
我相信这是文本文件的后遗症:
在打字机时代结束时,大多数设计都面向 72 CPL,这是从每英寸 12 个字符的间距乘以 6 英寸得出的(例如,参见 IBM Selectric)。这将确保每个边距至少有 1 英寸,当时美国政府已在 8 1/2×11" 纸上标准化。
许多纯文本文档仍然不符合传统的 72 CPL。
我认为这就像文档字符串经常在代码之外的上下文中使用一样,因此符合大多数纯文本文档用来尝试并尽可能保持一致的样式是有意义的。例如,man
页面的文本通常被换行到 72 个字符。通过将文档字符串限制为 72 个字符,输出help()
反映了这一点。
这个关于程序员的问题也可能是相关的。
文档字符串通常以其功能缩进,并以三引号开头和结尾:
def foo(bar, baz):
"""Frobnicate the foobars into baz
Parameters are ham and spammed.
"""
剩下 79 - 4 - 3 = 72 个字符。
行应该是 79 个字符的原因是它们可以适应 80 个字符宽的终端(显然它们仍然存在)。在文档字符串上使用 72 个字符的原因是,这意味着您在两边都有相等的填充(毕竟文档字符串是缩进的)并且仍然适合 80 个字符的宽度。