在这个时代，在代码文件中强制执行最大宽度为80个字符是否有合理的理由？

我利用更大屏幕的优势，将多个代码段放在一起。

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

实际上，我自己的代码也遵循类似的规则，但这仅仅是因为将代码打印到 A4页面上——80列的宽度与我想要的字体大小差不多。

但这只是个人偏好，可能不是你想要的(因为你希望弹药走另一条路)。

为什么你不质疑这个限制背后的理由呢? 说真的，如果没有人能找到一个好的理由来解释为什么会这样，那么你就有了一个很好的理由把它从你的编码标准中去掉。

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

不仅如此，如果行太长，人类的眼睛实际上在阅读文本方面也有问题。你很容易迷失方向。报纸有17英寸宽(或类似的宽度) ，但是你不会看到它们在整个页面上写字，杂志和其他印刷品也是如此。事实上，如果你把栏目保持在狭窄的范围内，阅读起来会更容易。

其他的答案已经很好地总结了事情，但是也值得考虑什么时候你可能想要复制粘贴一些代码到电子邮件中，或者如果不是代码，那么一个差异。

在这个时候，有一个“最大宽度”是有用的。

我认为不强制执行80个字符意味着最终的文字包装。
我的意思是，为最大宽度线选择的任何长度并不总是合适的，文字包装应该是一个可能的答案。
这可不像听起来那么简单。

它是在 jedit 中实现的
_{(资料来源: Jedit.org)} 提供换字

但它是 长久以来在日食中痛苦地错过了! (实际上是从2003年开始的) ，主要是因为 文本编辑器换行涉及:

• 换行信息是用于文本查看器、代码导航、垂直标尺。
• 取消包装的行信息是必需的功能，如要行，行编号标尺列，当前行高亮显示，保存文件。

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

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

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

但是先花点时间想想“这个代码真的那么糟糕以至于它不能存在于80个字符之内吗?”

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

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

正如其他人所说，我认为这是最好的(1)打印和(2)显示多个文件并排垂直。

我有两个20“1600x1200显示器，我坚持80列，因为它让我显示多个文本编辑器窗口并排。使用’6x13’字体(trad。Xterm font)80列占用480像素，加上滚动条和窗口边框。这允许在1600x1200显示器上有三个这种类型的窗口。在 Windows 上，Lucida Console 字体不会这样做(最小可用尺寸是7像素宽) ，但是一个1280x1024的显示器会显示两列，而一个1920x1200的显示器，比如 HP LP2465，会显示3。它还将在边上为各种资源管理器、属性和 VisualStudio 中的其他窗口留出一些空间。

此外，很长的文字行很难阅读。对于文本，最佳值为66个字符。有一点，过长的标识符开始起反作用，因为它们使得难以连贯地布局代码。良好的布局和缩进提供了关于代码结构的可视线索，有些语言(想到 Python)显式地使用缩进来实现这一点。

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

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

我认为将代码保留在80(或79)列的做法最初是为了支持人们在80列的哑终端或80列的打印输出上编辑代码而创建的。这些要求现在基本上已经消失，但仍有充分的理由保留80列规则:

• 避免在将代码复制到电子邮件、网页和书中时进行包装。
• 并排查看多个源窗口或使用并排 diff 查看器。
• 为了提高可读性。狭窄的代码可以快速阅读，而不必从一边到另一边扫描你的眼睛。

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

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

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

如果这个限制真的被强制执行，那么重新考虑代码和 没有也是一个很好的理由，将所有内容放在一行中。缩进也是如此——如果需要更高的级别，则需要重新考虑代码。

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

我有时发现它有点紧缩，但它有意义的 一些标准限制，所以它是80列。

下面是 Slashdot所涵盖的相同主题。

这里有一个老派的 Fortran 声明:

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

就我个人而言... ... 我把我所有的脑力(尽管很少)都用在了正确的编码上，当我可以把时间花在下一个函数上的时候，却不得不回到80个字符的极限，把所有的东西都打破是一件痛苦的事情。是的，Resharper 可以为我做到这一点，我想，但是它让我有点害怕，一个第三方产品正在决定我的代码布局和改变它(“请不要把我的代码分成两行 HAL。“哈尔?”).

尽管如此，我确实在一个相当小的团队中工作，而且我们所有的监视器都相当大，所以就目前而言，担心困扰我的程序员同事们的问题并不是一个大问题。

虽然有些语言似乎鼓励更长的代码行为了更划算(简称 if then 语句)。

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

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

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

我喜欢将宽度限制在100个字符左右，以便在宽屏显示器上使用两个 SxS 编辑器。我不认为有任何好的理由限制正好80个字符了。

打破80个字符是你做 同时编码，而不是事后。当然，评论也是如此。大多数编辑器可以帮助您查看80个字符的限制在哪里。

(这可能有点过时，但是在 Eclipse 中有一个选项，可以在保存代码时对其进行格式化(根据您想要的任何规则)。一开始这有点奇怪，但是过了一段时间之后，你就会开始接受格式化并不比生成的代码更在你的掌握之中。)

当你有一个重复的语句序列时，如果将它们分组成行，使得差异垂直排列，就可以更容易地看到相似点和差异点。

我认为下面的内容比我把它分成几行的时候可读性更好:

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个专栏了，但我认为我的观点仍然站得住脚，我只是举了一个糟糕的例子。它仍然证明了在一行中放置多个语句可以提高可读性。

如果我们有一个 这些，我们就不会有这个讨论了! ; -)

但是说真的，人们在回答中提出的问题是非常合理的。然而，原来的海报并没有反对一个限制，只是说80栏太少了。

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

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

我尽量把代码减少到80个字符左右，原因很简单: 超过80个字符就意味着我的代码变得太复杂了。过于冗长的属性/方法名称、类名称等等会造成与简洁的属性/方法名称同样多的危害。

我主要是一名 Python 编码员，因此这产生了两组限制:

1. 不要写很长的代码行
2. 不要缩进太多

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

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

如果你不想调用另一个函数然后跳回来的话，在像 C 这样的语言中遇到困难的时候，可以写一些助手函数并内联它们。在大多数情况下，编译器将为您智能地处理事情。

我一整天都在不同的地方而且我没有22英寸的显示器。我不知道我会不会。当然，对于喜欢使用箭头编码和300字符行的纯写程序员来说，这没什么意思。

打印等宽字体的默认大小是(在 A4纸上)80列66行。

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

代码只是环境的一部分。

我已经把代码扩大到100个字符，这些字符可以轻松地放在我 Macbook 上不到一半的屏幕上。120个字符可能是行变得太长和太复杂之前的极限。您不希望变得太宽，否则会鼓励复合语句和深度嵌套的控制结构。

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

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

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

我尽量把台词写在80栏以下。最大的原因是，我经常发现自己使用 grep和 less浏览我的代码时，在命令行工作。我真的不喜欢终端如何破坏长的源代码行(他们毕竟不是为这项工作而生的)。另一个原因是，我发现它看起来更好，如果一切都符合行，而不是由编辑打破。例如，让长函数调用的参数在彼此之间和类似的东西之间很好地对齐。

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

大约17年前，我让自己的代码扩展到88列，因为我开始使用 诺伯做所有的事情，而88列正是使用 TeX 打印得很好的文档所需要的。

我只缩进了两个空格，但是多出来的空间真是太棒了。

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

因此，我们都同意采用一种编码标准，列数(大约)为75个字符。

使用比例字体。

我是认真的。我通常可以在不牺牲可读性或可印刷性的情况下得到一行100-120个字符的等值。事实上，使用好的字体(比如 Verdana)和语法着色阅读更加容易。这几天看起来有点奇怪，但你很快就习惯了。

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

不能保持在80岁的原因是我宁愿

• 更喜欢有标识符含义的较长的名称
• 不必为 C 中的结构和枚举使用 typedef (它们很糟糕，它们隐藏了有用的信息!)！如果你不相信，可以去问问 Peter van der Linden 在“ Deep C Secsecret”中的描述) ，所以这个代码比 typedef 狂热者的代码有更多的 struct FOO func(struct BAR *aWhatever, ...)。

根据这些规则，只有80个字符/行会导致难看的行包装，其频率超出了我的认为可以接受的范围(大多数是在原型和函数定义中)。

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

这段代码有94个字符长，而且类名很短(按照 GWT 标准)。这将是困难的阅读2行，它是非常可读的一行。 为了实用起见，因此允许“向后兼容”，我认为100个字符是合适的宽度。