严重地。在22英寸显示器上，它可能只覆盖整个屏幕的四分之一。我需要一些弹药才能降低此规则。

我并不是说应该没有限制；我只是说80个字符很小。

解决方案

我利用大屏幕的优势，使多个代码彼此相邻。

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

对于我自己的代码，我实际上遵循类似的规则，但仅是因为将代码打印到A4页的80列中，才适合所需字体大小的正确宽度。

但这是个人喜好，可能不是我们追求的(因为我们希望弹药走另一条路)。

我们没有严重质疑该限制背后的原因吗，如果没有人能提出一个很好的理由说明理由，那么我们有很好的理由将其从编码标准中删除。

我们应该这样做是为了没有22英寸宽屏显示器的每个人。就个人而言，我在17英寸4：3显示器上工作，发现宽度远远不够。但是，我也有3个这样的显示器，所以我仍然有很多可用的屏幕空间。

不仅如此，如果行太长，人眼实际上在阅读文本时也会遇到问题。在我们所在的行上迷路很容易。报纸的宽度为17英寸(或者类似的东西)，但我们看不到它们在页面上始终书写，杂志和其他印刷品也是如此。如果我们将列保持狭窄，则实际上更容易阅读。

其他答案已经很好地总结了问题，但是当我们可能希望将一些代码复制并粘贴到电子邮件中时也值得考虑。

这是具有"最大宽度"的时间。

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

它是通过jeditalt文本http://www.jedit.org/images/logo64.png实现的，该文本提供自动换行

但是从那一刻起，它就被人们深深地遗忘了！ (实际上是2003年以来)，主要是因为文本编辑器的自动换行涉及：

• 换行信息适用于文本查看器，代码导航和垂直标尺。
• 对于诸如goto行，行编号标尺列，当前行突出显示，保存文件之类的功能，需要未包装的行信息。

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

下一个这样做的人可能有17英寸的屏幕，或者可能需要大字体才能阅读文本。由于以前的屏幕限制，此限制必须在某个地方，并且惯例为80个字符。我们能想到任何新的标准(120)和为什么最好使用其他字体，而不是"这是适合我的Xpt字体的显示器"？

请记住，每条规则总是有例外，因此我们有一行特定的代码行或者代码块，有意义的是超过80个字符，然后成为叛逆者。

但是，请花些时间先想一下："这段代码真的很糟糕，无法容纳80个字符吗？"

超长线很难阅读。仅仅因为我们可以在显示器上显示300个字符，并不意味着我们应该使行长。对于一个语句，300个字符也太复杂了，除非我们别无选择(调用需要一堆参数)。

我通常使用80个字符，但如果执行此命令，我将超越此限制，这意味着将换行符放置在不希望的位置。

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

我有两个20" 1600x1200显示器，我坚持80列，因为它可以让我并排显示多个文本编辑器窗口。使用'6x13'字体(trad。xterm字体)，80列占用480像素以及滚动条和窗口边框。这样一来，一个1600x1200监视器上可以拥有三个这种类型的窗口。在Windows上，Lucida Console字体不能完全做到这一点(最小可用大小为7像素宽)，但是1280x1024监视器将显示两列，并且1920 x 1200监视器(例如HP LP2465)将显示3. 它的侧面还将留出一些空间，可容纳Visual Studio中的各种资源管理器，属性和其他窗口。

另外，很难阅读很长的文本行。对于文本，最佳为66个字符。有时，过长的标识符会适得其反，因为它们使连贯地布置代码变得困难。良好的布局和缩进提供了有关代码结构的视觉提示，某些语言(想到了Python)为此明确使用了缩进。

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

请注意，我们可以在此处获取Windows版本的" 6x13"字体。

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

• 为了避免在将代码复制到电子邮件，网页和书籍中时自动换行。
• 要并排或者使用并排的diff查看器来查看多个源窗口。
• 提高可读性。可以快速读取狭窄的代码，而不必从一侧到另一侧扫描眼睛。

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

这些天来80个字符是一个荒谬的限制。将代码行拆分为有意义的行，而不是根据任意字符数限制。

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

如果确实执行了限制，这也是重新考虑代码而不是将所有内容放在一行中的一个很好的理由。如果我们需要很多层次的代码需要重新考虑，则缩进是相同的。

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

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

这是Slashdot涵盖的同一主题。

这是一个古老的Fortran声明：

我唯一要保留在80个字符以内的内容是我的评论。

就个人而言...我将所有的脑力(几乎没有)都投入到正确的编码上，当我可能将时间花在下一个功能上时，不得不回过头来将所有内容分解为80个字符的限制是很痛苦的。是的，我想Resharper可以为我做这件事，但随后令我有些惊讶的是，第三方产品正在决定我的代码布局并对其进行更改("请不要将我的代码分成两行：HAL。HAL？" )。

就是说，我确实在一个很小的团队中工作，并且我们所有的监视器都很大，所以就目前而言，担心让我的程序员感到困扰的问题并不是什么大问题。

似乎有些语言会鼓励使用更长的代码行，以期为之付出更大的代价(如果则使用then语句，则简明扼要)。

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

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

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

我希望将宽度限制为100个字符左右，以允许在宽屏显示器上使用两个SxS编辑器。我认为再也没有任何理由限制80个字符了。

编码时不要超过80个字符，而不是事后。当然，评论也一样。大多数编辑器可以查看80个字符的限制。

(这可能有点OT，但是在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个字符以内的原因很简单：太多了，这意味着我的代码变得太复杂了。过于冗长的属性/方法名称，类名称等造成的损害与简洁的损害一样大。

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

• 不要写很长的代码
• 不要缩进太多

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

在Python中，以可读性为代价编写相对简洁的代码(请参阅codegolf)很容易，但是以可读性为代价编写冗长的代码甚至更容易。辅助方法不是一件坏事，辅助类也不是坏事。过多的抽象可能是一个问题，但这是编程的另一个挑战。

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

我整天并肩而行，没有22英寸显示器。我不知道我是否愿意。当然，这对于只喜欢使用箭头编码和300个字符的行的只写式程序员来说没什么兴趣。

默认尺寸下的等宽字体打印(在A4纸上)为80列66行。

对此已经有了很多好的答案，但是值得一提的是，在IDE中，我们可能在左侧有一个文件列表，在右侧有一个功能列表(或者任何其他配置)。

代码只是环境的一部分。

我已将代码扩展到100个字符，可以舒适地放置在Macbook不到一半的屏幕上。 120个字符可能是行开始变得太长和太复杂之前的限制。我们不想太宽泛，否则会鼓励使用复合语句和深层嵌套的控制结构。

正确的余量是自然界告诉我们执行额外的方法重构的方式。

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

是的，因为即使在这个时代，我们中的一些人仍在终端上进行编码(好的，主要是终端仿真器)，在该显示器上只能显示80个字符。因此，至少对于我做的编码，我真的很欣赏80个字符的规则。

我尝试将行数保持在80列以下。最强烈的原因是，在命令行工作时，我经常使用grep和less来浏览代码。我真的不喜欢终端如何中断长的源代码行(毕竟，这些源代码都不适合该工作)。另一个原因是，我发现如果所有内容都适合该行并且未被编辑器破坏，则看起来会更好。例如，具有长函数调用的参数在彼此之间以及相似的内容之间很好地对齐。

我强迫我的学生挤成80列，以便我可以打印出他们的代码并将其标记出来。

大约在17年前，我让自己的代码扩展到88列，因为我开始使用Noweb进行所有操作，而88列恰好适合使用TeX打印的文档。

我只缩进两个空格，但是多余的空间很棒。

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

因此，我们所有人都同意一种列数为(大约)75个字符的编码标准。没关系。

使用比例字体。

我是认真的。通常，我可以在一行中获得100-120个字符的等价性，而不会牺牲可读性或者可打印性。实际上，使用好的字体(例如Verdana)和语法着色甚至更容易阅读。几天后看起来有些奇怪，但是我们很快就习惯了。