text-editor - 在当今时代，是否有正当理由在代码文件中强制规定最大宽度为 80 个字符？

Question

严重地。在 22 英寸显示器上，它可能只覆盖屏幕的四分之一。我需要一些弹药来打破这条规则。

我并不是说不应该有限制。我只是说，80 个字符非常小。

score 278 · Accepted Answer

我认为将代码保留为 80（或 79）列的做法最初是为了支持人们在 80 列的哑终端或 80 列的打印输出上编辑代码。这些要求现在大部分已经消失，但仍然有充分的理由保留 80 列规则：

在将代码复制到电子邮件、网页和书籍时避免换行。
并排查看多个源窗口或使用并排差异查看器。
为了提高可读性。无需左右扫视即可快速读取窄码。

我认为最后一点是最重要的。尽管过去几年显示器的尺寸和分辨率都在增长，但眼睛却没有。

score 82 · Accepted Answer

80 列文本格式的起源早于 80 列终端——IBM 打孔卡可以追溯到1928 年，它的遗产是 1725 年的纸带！这让人想起（杜撰的）故事，即美国的铁路轨距是由罗马英国的战车车轮的宽度决定的。

我有时觉得它有点束缚，但有一些标准限制是有意义的，所以它是 80 列。

这是Slashdot涵盖的相同主题。

这是一个老式的 Fortran 声明：

score 58 · Accepted Answer

如今，80 个字符是一个荒谬的限制。在有意义的地方拆分代码行，而不是根据任意字符限制。

score 36 · Accepted Answer

为了每个没有 22 英寸宽屏显示器的人，你应该这样做。就我个人而言，我使用的是 17 英寸 4:3 显示器，我发现它的宽度绰绰有余。但是，我也有 3 个这样的显示器，所以我还有很多可用的屏幕空间。

不仅如此，如果行太长，人眼实际上会出现阅读文本的问题。很容易迷失在哪条线上。报纸有 17 英寸宽（或类似的东西），但你看不到它们在页面上一直写着，杂志和其他印刷品也是如此。如果将列保持窄，实际上更容易阅读。

score 26 · Accepted Answer

当您有一个重复的语句序列时，如果将它们分成几行以使差异垂直对齐，则可以更容易地看到相似之处和不同之处。

我认为以下内容比将其拆分为多行时更具可读性：

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

更新：在评论中，有人建议这将是执行上述操作的更简洁的方式：

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY;

虽然它现在适合 80 列，但我认为我的观点仍然成立，我只是选择了一个坏例子。它仍然证明在一行中放置多个语句可以提高可读性。

score 22 · Accepted Answer

22

以默认大小打印等宽字体（在 A4 纸上）为 80 列 x 66 行。

于 2008-10-03T00:55:56.357 回答

score 16 · Accepted Answer

我利用更大屏幕的优势让多段代码彼此相邻。

你不会从我这里得到任何弹药。事实上，我不希望看到它发生变化，因为在紧急情况下，我仍然会看到需要从文本控制台更改代码的罕见情况。

score 14 · Accepted Answer

超长的行更难阅读。仅仅因为你可以在你的显示器上显示 300 个字符并不意味着你应该让行那么长。300 个字符对于一个语句来说也太复杂了，除非你别无选择（一个需要一大堆参数的调用。）

作为一般规则，我使用 80 个字符，但如果强制执行它意味着在不受欢迎的位置放置换行符，我会超出这个范围。

score 9 · Accepted Answer

我唯一强制保持在 80 个字符以内的是我的评论。

就个人而言...我将所有的脑力（几乎没有）都投入到正确的编码上，当我可以花时间在下一个功能上时，不得不返回并将所有内容分解为 80 个字符的限制是很痛苦的. 是的，我想 Resharper 可以为我做这件事，但是让我有点害怕的是，第 3 方产品正在对我的代码布局做出决定并对其进行更改（“请不要将我的代码分成两行 HAL。HAL？” ）。

也就是说，我确实在一个相当小的团队工作，而且我们所有的显示器都相当大，所以担心困扰我的程序员同事的事情就这一点而言并不是一个大问题。

似乎有些语言为了获得更多收益而鼓励更长的代码行（简写 if then 语句）。

score 7 · Accepted Answer

我有两个 20" 1600x1200 显示器，我坚持使用 80 列，因为它可以让我并排显示多个文本编辑器窗口。使用 '6x13' 字体（trad.xterm 字体）80 列占用 480 像素加上滚动条和窗口边框。这允许一个人在 1600x1200 显示器上拥有三个这种类型的窗口。在 Windows 上，Lucida Console 字体不会完全做到这一点（最小可用尺寸为 7 像素宽），但 1280x1024 显示器将显示两列和HP LP2465等 1920x1200 显示器将显示 3。它还会在侧面为 Visual Studio 的各种资源管理器、属性和其他窗口留出一点空间。

此外，很长的文本行很难阅读。对于文本，最佳值为 66 个字符。有一点是，过长的标识符开始适得其反，因为它们难以连贯地布局代码。良好的布局和缩进为代码结构提供了视觉提示，并且某些语言（想到 Python）为此明确使用缩进。

但是，Java 和 .Net 的标准类库往往具有非常长的标识符，因此不一定能保证能够做到这一点。在这种情况下，使用换行符布局代码仍然有助于使结构明确。

请注意，您可以在此处获得“6x13”字体的 Windows 版本。

score 6 · Accepted Answer

其他答案已经很好地总结了事情，但是当您可能想要将一些代码复制并粘贴到电子邮件中时，或者如果不是代码然后是差异，也值得考虑。

那是拥有“最大宽度”有用的时候。

score 6 · Accepted Answer

人们说长行代码往往很复杂。考虑一个简单的 Java 类：

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

这是 94 个字符长，并且类名很短（按照 GWT 标准）。两行很难阅读，而单行可读性很强。务实并因此允许“向后兼容性”，我会说 100 个字符是正确的宽度。

score 5 · Accepted Answer

您不是唯一要维护您的代码的人。

下一个人可能有 17 英寸的屏幕或可能需要大字体来阅读文本。限制必须在某个地方，并且由于以前的屏幕限制，惯例是 80 个字符。你能想到任何新标准 (120) 和为什么使用“这就是我的 Xpt 字体适合我的显示器的东西”是一个好主意？

请记住，每条规则总是有例外，所以如果你有一个特定的代码行或代码块，超过 80 个字符是有意义的，那么你就是一个反叛者。

但请先花点时间思考“这段代码真的那么糟糕，不能保存在 80 个字符内吗？”

score 5 · Accepted Answer

在 Linux 编码标准中，它们不仅保持 80 个字符的限制，而且还使用 8 个空格缩进。

部分原因是，如果您到达右边距，您应该考虑将缩进级别移动到单独的函数中。

这将使代码更清晰，因为无论缩进长度如何，具有许多嵌套控制结构的代码都难以阅读。

score 5 · Accepted Answer

我已经将我的代码扩大到 100 个字符，这在我的 Macbook 上不到一半的屏幕中可以轻松容纳。120 个字符可能是行开始变得太长和太复杂之前的限制。你不想变得太宽，否则你鼓励复合语句和深度嵌套的控制结构。

右边距是大自然告诉您执行额外方法重构的方式。

score 5 · Accepted Answer

我想知道这是否会在当今时代引起更多问题。请记住，在 C（可能还有其他语言）中，函数名的长度是有规则的。因此，您经常会在 C 代码中看到非常难以理解的名称。好消息是他们不使用很多空间。但每次我查看 C# 或 Java 等语言的代码时，方法名称通常很长，这使得将代码保持在 80 个字符的长度几乎是不可能的。我认为今天 80 个字符无效，除非您需要能够打印代码等。

score 4 · Accepted Answer

正如其他人所说，我认为它最适合（1）打印和（2）垂直并排显示多个文件。

score 4 · Accepted Answer

我喜欢将宽度限制在 100 个字符左右，以便在宽屏显示器上允许两个 SxS 编辑器。我认为不再有任何充分的理由限制 80 个字符。

score 4 · Accepted Answer

作为我的雇主编码指南的作者，我将行长从 80 增加到 132。为什么这个值？好吧，就像其他人指出的那样，80 是许多旧硬件终端的长度。132也是！这是终端处于宽模式时的线宽。任何打印机也可以在宽模式下使用压缩字体制作硬拷贝。

不留在80的原因是我宁愿

更喜欢具有标识符含义的较长名称
不用担心 C 中结构和枚举的 typedef（它们很糟糕，它们隐藏了有用的信息！如果您不相信，请在“Deep C Secrets”中询问 Peter van der Linden），因此代码struct FOO func(struct BAR *aWhatever, ...)不仅仅是 typedef 狂热者的代码.

在这些规则下，每行只有 80 个字符会导致丑陋的换行比我认为可以接受的更频繁（主要是在原型和函数定义中）。

score 3 · Accepted Answer

已经有很多很好的答案，但值得一提的是，在您的 IDE 中，左侧可能有一个文件列表，右侧有一个函数列表（或任何其他配置）。

你的代码只是环境的一部分。

score 3 · Accepted Answer

使用比例字体。

我是认真的。我通常可以在一行中获得 100-120 个字符的等效值，而不会牺牲可读性或可打印性。事实上，使用好的字体（例如，Verdana）和语法着色会更容易阅读。这几天看起来有点奇怪，但你很快就习惯了。

score 2 · Accepted Answer

我认为不强制使用 80 个字符意味着最终会自动换行。
IMO，为最大宽度线选择的任何长度并不总是合适的，换行应该是一个可能的答案。
这并不像听起来那么容易。

它在提供自动换行的 jedit （_来源：_jedit.org_）中实现

但它在很久以前就在日食中被深深地错过了！（实际上是从 2003 年开始），主要是因为文本编辑器的自动换行涉及：

换行信息用于文本查看器、代码导航、垂直标尺。
诸如转到行、行编号标尺列、当前行突出显示、保存文件等功能需要展开的行信息。

score 2 · Accepted Answer

我尝试将内容保持在 80 个字符左右，原因很简单：太多意味着我的代码变得太复杂了。过于冗长的属性/方法名称、类名称等会造成与简洁名称一样多的危害。

我主要是一名 Python 编码员，所以这产生了两组限制：

不要写长行代码
不要缩进太多

当您开始达到两个或三个缩进级别时，您的逻辑就会变得混乱。如果您不能在同一页面上保留单个块，那么您的代码就会变得过于复杂和难以记住。如果您不能将单行保持在 80 个字符以内，那么您的行就会变得过于复杂。

在 Python 中以牺牲可读性为代价编写相对简洁的代码（参见 codegolf）很容易，但以牺牲可读性为代价编写冗长的代码更容易。辅助方法不是坏事，辅助类也不是。过度抽象可能是一个问题，但这是编程的另一个挑战。

如果对 C 等语言有疑问，请编写辅助函数并内联它们，如果您不想调用另一个函数并跳回的开销。在大多数情况下，编译器会为您智能地处理事情。

score 2 · Accepted Answer

我整天都在并排比较，我没有一个该死的 22 英寸显示器。我不知道我会不会。当然，这对于喜欢箭头编码和 300 字符行的纯写程序员来说没什么兴趣。

score 1 · Accepted Answer

实际上，我对自己的代码遵循了类似的规则，但这只是因为将代码打印到 A4 页面 - 80 列的宽度大约是我想要的字体大小的正确宽度。

但这是个人喜好，可能不是你想要的（因为你想让弹药走另一条路）。

你不质疑限制背后的原因 - 严肃地说，如果没有人能提出一个很好的理由，那么你就有一个很好的理由将它从你的编码标准中删除。

score 1 · Accepted Answer

是的，因为即使在这个时代，我们中的一些人也在终端上编码（好吧，主要是终端模拟器），显示器只能显示 80 个字符。所以，至少对于我所做的编码，我真的很欣赏 80 字符规则。

score 0 · Accepted Answer

我仍然认为限制不限于视觉部分。当然，现在显示器和分辨率足够大，可以在一行中显示更多字符，但它是否增加了可读性？

如果确实执行了限制，那么重新考虑代码而不是将所有内容放在一行中也是一个很好的理由。缩进也是一样——如果你需要更多的层次，你的代码需要重新考虑。

score 0 · Accepted Answer

在 80 个字符处中断是您在编码时所做的事情，而不是之后。当然，评论也是如此。大多数编辑可以帮助您了解 80 个字符的限制在哪里。

（这可能有点 OT，但是在 Eclipse 中，有一个选项可以在保存代码时格式化代码（根据您想要的任何规则）。起初这有点怪异，但过了一段时间你开始接受与生成的代码一样，格式化不再掌握在您手中。）

score 0 · Accepted Answer

如果我们有其中之一，我们将不会进行此讨论！;-)

但说真的，人们在回答中提出的问题是非常合理的。然而，最初的发布者并没有反对限制，只是 80 列太少了。

通过电子邮件发送代码片段的问题有一些优点。但是考虑到大多数电子邮件客户端对预先格式化的文本所做的邪恶事情，我认为换行只是您的问题之一。

至于打印，我通常发现 100 个字符行将非常适合打印页面。

score 0 · Accepted Answer

我尝试将行数保持在 80 列以下。最强烈的原因是我经常发现自己在命令行工作时使用grep并less浏览我的代码。我真的不喜欢终端如何打破长的源代码行（它们毕竟不是为那项工作而生的）。另一个原因是，我发现如果所有内容都符合要求并且没有被编辑器破坏，它看起来会更好。例如，长函数调用的参数在彼此和类似的东西下方很好地对齐。

score 0 · Accepted Answer

我强迫我的学生挤进 80 列，这样我就可以打印出他们的代码并进行标记。

大约 17 年前，我让自己的代码扩展到 88 列，因为我开始使用Noweb做所有事情，而 88 列适合使用 TeX 打印的精美文档。

我只缩进了两个空格，但额外的空间很棒。

score 0 · Accepted Answer

我们最近做了一个调查。几乎每个人都在 gnome 终端中使用vim，如果我们进行垂直拆分，列数是 78 作为标准字体大小和屏幕分辨率 1280x1024。

所以我们都同意一个列数为（大约）75 个字符的编码标准。没关系。

text-editor - 在当今时代，是否有正当理由在代码文件中强制规定最大宽度为 80 个字符？

32 回答 32

Related

Reference