Question

严重。在一台22英寸的显示器上，它只能覆盖屏幕的四分之一。我需要一些弹药来制定这个规则。

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

Answer 1

我认为将代码保存到80（或79）列的做法最初是为了支持人们在80列哑终端或80列打印输出上编辑代码而创建的。这些要求现在已基本消失，但仍有正当理由保持80列规则：

在将代码复制到电子邮件，网页和图书时避免包装。
并排查看多个源窗口或使用并排差异查看器。
提高可读性。可以快速读取窄代码，而无需从一侧到另一侧扫描您的眼睛。

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

Answer 2

80列文本格式的起源早于80列终端 - IBM打卡可以追溯到1928！这让人想起(apocryphal)故事，美国铁路轨距是由罗马英国战车轮的宽度决定的。

我有时觉得它有点紧缩，但是某些标准限制是有意义的，所以它是80列。

以下是Slashdot涵盖的相同主题。

这是一个老式的Fortran声明：

Answer 3

这些天，80个字符是一个荒谬的限制。将代码行拆分到合理的位置，而不是根据任意字符限制。

Answer 4

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

不仅如此，如果线条太长，人眼实际上在阅读文字方面存在问题。在你所在的哪条线路上迷路太容易了。报纸横跨17英寸（或类似的东西），但你看不到它们在页面上一直写着，杂志和其他印刷品一样。如果你保持列的缩小，它实际上更容易阅读。

Answer 5

以默认尺寸打印等宽字体（在A4纸上）80列66行。

Answer 6

当您有一系列重复较小变化的陈述时，如果它们被分组为线条以便差异垂直对齐，则可以更容易地看到相似点和差异。

我认为，如果我将它分成多行，那么以下内容的可读性要大得多：

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列，但我认为我的观点仍然存在，我只是选了一个坏榜样。它仍然证明在一行上放置多个语句可以提高可读性。

Answer 7

我利用更大屏幕的优势，在彼此旁边放置多段代码。

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

Answer 8

超长线条难以阅读。仅仅因为你可以在显示器上获得300个字符并不意味着你应该把线条变长。除非你没有选择（一个需要大量参数的调用），否则300个字符对于语句来说也太复杂了。）

我使用80个字符作为一般规则但我会超越它，如果执行它意味着在不合适的位置放置换行符。

Answer 9

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

就个人而言......我正在把所有的脑力（都没有）投入到正确的编码中，当我花费我的时间时，我必须回过头来在80个字符的限制内打破一切是很痛苦的。下一个功能。是的，Resharper可以为我做这些我想但是然后它让我感到有点不对，第三方产品正在对我的代码布局做出决定并改变它（“请不要将我的代码分成两行HAL。哈尔？” ）。

那就是说，我在一个相当小的团队工作，我们所有的监视器都相当大，所以担心我的同事程序员的困扰并不是一个大问题。

似乎有些语言为了更多的利益而鼓励更长的代码行（如果那么陈述的话就是空手）。

Answer 10

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

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

但是，Java和.Net的标准类库往往具有非常长的标识符的优势，因此无法保证能够执行此操作。在这种情况下，使用换行符布局代码仍然有助于使结构显式化。

请注意，您可以获得'6x13'字体Here的Windows版本。

Answer 11

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

下一个人可能有一个17英寸的屏幕或者可能需要大字体来阅读文本。限制必须在某处，并且由于之前的屏幕限制，80个字符是惯例。你能想到任何新标准（ 120）以及为什么使用那个其他的好主意然后“那是什么适合我在Xpt字体的显示器上？”

请记住，每条规则都有例外，所以你有一个特定的代码行或代码块，超过80个字符才有意义，然后才能成为反叛者。

但是先花时间思考“这段代码真的那么糟糕，它不能生活在80个字符内吗？”

Answer 12

其他答案已经很好地总结了一些事情，但是当你想要复制＆amp;将一些代码粘贴到电子邮件中，或者如果不是代码则粘贴到差异。

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

Answer 13

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

Answer 14

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

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

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

Answer 15

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

Answer 16

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

不停留在80的原因是我宁愿

更喜欢具有标识符含义的较长名称
不打扰C中结构和枚举的typedef（它们很糟糕，它们隐藏了有用的信息！如果你不相信，请问Peter Deep der Linden在“Deep C Secrets”中），所以代码有更多{{ 1}}比typedef狂热分子的代码。

根据这些规则，只有80个字符/行会导致丑陋的线条包裹比我认为可接受的更多（主要是在原型和函数定义中）。

Answer 17

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

这是94个字符长，类名很短（按GWT标准）。它很难在2行读取，并且在一行上非常易读。由于务实，因而允许“向后兼容”，我会说100个字符是正确的宽度。

Answer 18

使用比例字体。

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

Answer 19

我已经将我的代码扩展到100个字符，这在我的Macbook上不到一半的屏幕上非常适合。在行开始变得太长和复杂之前，120个字符可能是限制。你不希望得到太多其他的鼓励复合语句和深层嵌套的控制结构。

正确的边缘是大自然告诉你执行extra method refactoring的方式。

Answer 20

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

Answer 21

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

它是在jedit 中实现的提供自动换行的_{（来源：jedit.org）}

但它是bitterly missed in eclipse from a looong time！（事实上自2003年起），主要是因为word wrap for text editor涉及：

包装行信息用于文本查看器，代码导航，垂直标尺。
goto line，行编号标尺列，当前行突出显示，保存文件等功能需要打开行信息。

Answer 22

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

我主要是一个Python编码器，所以这会产生两组限制：

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

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

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

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

Answer 23

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

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

Answer 24

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

Answer 25

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

但这是个人偏好，可能不是你所追求的（因为你想让弹药走向另一个方向）。

你有什么不质疑这个限制背后的原因 - 严重的是，如果没有人能够提出一个很好的理由，那么你就可以从你的编码标准中删除它。

Answer 26

我整天都在并排徘徊，我没有一台22英寸的显示器。我不知道我是否愿意。当然，对于只有编程的程序员来说，享受箭头编码和300-char行是没什么兴趣的。

Answer 27

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

Answer 28

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

大约17年前，我将自己的代码扩展到88列，因为我开始使用Noweb完成所有操作，88列是使用TeX打印得很好的文档。

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

Answer 29

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

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

Answer 30

如果我们有these之一，我们就不会讨论了！ ; - ）

但严重的是，人们在答案中提出的问题是非常合法的。然而，原始海报并没有反对限制，只是80列太少了。

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

至于打印，我通常会发现100个字符行非常可以轻松地适合打印页面。

Answer 31

在进行编码时，你可以做80个字符，而不是之后。当然，与评论相同。大多数编辑都可以帮助您查看80个字符的限制。

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

Answer 32

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

如果确实强制执行限制，那么重新考虑代码也是一个很好的理由，不将所有内容放在一行中。缩进也是如此 - 如果你需要很多级别，你的代码需要重新思考。

是否有正当理由在当天和年龄的代码文件中强制执行最大宽度为80个字符？

32 个答案: