是否有一个有效的理由在代码文件中强制执行最大宽度为80个字符的date和年龄？
认真。 在一台22英寸的显示器上，它只能覆盖屏幕的四分之一，我需要一些弹药来打破这个规则。
我不是说没有限制， 我只是说，80个字是非常小的。
我认为将代码保留为80（或79）列的做法最初是为了支持人们在80列哑terminal或80列打印输出上编辑代码而创build的。 这些要求现在大都消失了，但仍然有正当的理由来维持80列的规则：
- 将代码复制到电子邮件，网页和书籍时要避免包装。
- 要并排查看多个源窗口或使用并排的差异查看器。
- 提高可读性。 窄码可以快速读取，而不必一边扫描你的眼睛。
我认为最后一点是最重要的。 尽pipe过去几年中显示器的尺寸和分辨率都有所增长，但眼睛却没有 。
80列文本格式的起源早于80列terminal – IBM打卡的起源可追溯到1928年 ！ 这让人联想起美国铁路规格是由罗马英国的战车车轮宽度决定的（杜撰）故事。
我有时觉得它有点收缩，但有一些标准的限制是有道理的，所以有80列。
这是Slashdot涵盖的同一主题。
这是一个古老的Fortran声明：
现在80个字符是一个荒谬的限制。 将代码行拆分为合理的代码行，而不是根据任意字符限制。
你应该为了没有22英寸宽屏显示器的人而使用它。 就我个人而言，我在一台17英寸的4：3显示器上工作，而且我发现这个宽度足够大。 不过，我也有3台显示器，所以我仍然有很多可用的屏幕空间。
不仅如此，如果线条太长，人眼在阅读文本方面也会遇到问题。 你在哪条线上迷路很容易。 报纸是17英寸（或者像这样的东西），但是你不会看到它们在整个页面上书写，杂志和其他印刷品也是如此。 如果你把列缩小的话，它实际上更容易阅读。
以默认尺寸打印等宽字体是（在A4纸上）80列66行。
当你有一系列重复less量变化的陈述时，如果将它们分组成一行以便差异垂直alignment，可以更容易地看到相似性和差异性。
我认为，如果我把它分成多行的话，下面的内容会更可读：
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; } 更新：在评论的有人build议，这将是一个更简洁的方式做到以上几点：
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列，但我认为我的观点依然存在，我只是挑了个坏榜样。 它仍然表明，将多个语句放在一行可以提高可读性。
我使用大屏幕的优势，在彼此旁边有多个代码段。
你不会得到我的任何弹药。 事实上，我不愿意看到它发生了变化，因为在紧急情况下，我仍然会看到极less数情况下需要从文本控制台更改代码。
超长线条难以阅读。 仅仅因为你可以在你的显示器上显示300个字符，并不意味着你应该长这么长。 对于一个语句来说，300个字符也太复杂了，除非你没有select（一个需要大量参数的调用）。
我通常使用80个字符作为一般规则，但是如果强制执行则意味着在不希望的位置放置换行符。
我强制要保留在80个字符以内的是我的评论。
就个人而言……我把我所有的大脑力量（只有less量的东西）用于编码，当我可以花费我的时间在下一个函数上时，必须返回并在80个字符的极限处打破所有的事情是一种痛苦。 是的，Resharper可以为我做，我想，但它吓到我了一点，第三方产品正在做我的代码布局的决定，并改变它（“请不要把我的代码分成两行HAL。哈？ ）。
也就是说，我在一个相当小的团队中工作，而且我们所有的显示器都相当大，所以担心我的程序员不应该担心这个问题。
似乎虽然有些语言鼓励更长的代码行，为了更多的压力（如果然后陈述，短手）。
我有两个20“1600×1200显示器，我坚持80列，因为它允许我并排显示多个文本编辑器窗口。使用'6×13'字体（传统.xterm字体）80列占用480像素加上滚动条和窗口边框，这样就可以在1600×1200的显示器上显示三个这种types的窗口，在窗口上，Lucida Console字体不会这样做（最小可用尺寸为7像素宽），但是1280×1024显示器会显示两列，一个1920×1200的显示器如HP LP2465将会显示3.它还会在Visual Studio的各种浏览器，属性和其他窗口的旁边留下一些空间。
另外很长的文本行很难阅读。 对于文字，最佳的是66个字符。 有一点，标识符过长会导致相反的结果，因为它们使编码难以一致。 良好的布局和缩进提供了关于代码结构的可视提示，并且一些语言（Python浮现在脑后）明确地使用了缩进。
但是，用于Java和.Net的标准类库往往具有很长的标识符的优势，所以不一定能保证能够做到这一点。 在这种情况下，使用换行符来编排代码仍然有助于使结构变得清晰。
请注意，您可以在这里获得Windows版本的“6×13”字体。
其他的答案已经很好地总结了一些东西，但也值得考虑当你可能想复制和粘贴一些代码到电子邮件，或者如果不是代码，然后差异。
那是一个“最大宽度”有用的时间。
你不是唯一一个要维护你的代码的人。
下一个人可能有一个17英寸的屏幕，或者可能需要大字体来读取文本。由于以前的屏幕限制，限制必须在某个地方，80个字符是惯例。你能想到任何新的标准（120）和为什么使用其他的那么是一个好主意“这就是Xpt字体在我的显示器上的东西？”
请记住，每个规则总是有例外，所以你有一个特定的代码行或代码块，超过80个字符，然后成为一个反叛者。
但是先花时间思考一下，“这个代码真的很糟糕，它不能生活在80个字符之内吗？”
我想知道这是否会在这个时代造成更多的问题。 请记住，在C（也可能是其他语言）中，函数名称可以有多长时间。 因此，您经常在C代码中看到非常难以理解的名称。 好处是他们不占用太多的空间。 但是，每当我用C＃或Java等语言查看代码时，方法名称通常很长，这使得代码长度不能超过80个字符。 我不认为今天80个字符是有效的，除非你需要能够打印代码等。
人们说很长的一段代码往往是复杂的。 考虑一个简单的Java类：
public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {
这是94个字符长，类名相当短（按GWT标准）。 在两行上阅读将会很困难，并且在一行上非常可读。 为了实现它，从而允许“向后兼容”，我认为100个字符是正确的宽度。
正如其他人所说，我认为最好是（1）打印和（2）垂直并排显示多个文件。
在Linux编码标准中，它们不仅保留了80个字符的限制，而且还使用了8个空格缩进。
部分原因是，如果您达到了正确的边距，您应该考虑将缩进级别转换为单独的函数。
这将使代码更清晰，因为不pipe缩进长度如何，读取具有许多嵌套控制结构的代码都更加困难。
我喜欢将宽度限制在100字左右，以便在宽屏显示器上显示两个SxS编辑器。 我不认为有足够的理由为正好80个字符的限制了。
我已经将我的代码扩展到了100个字符，这在我的Macbook上还不到我的屏幕的一半。 在行开始变得太长和复杂之前，120个字符可能是限制。 你不想太宽泛，否则你鼓励复合语句和深层嵌套的控制结构。
正确的边界是自然的告诉你执行一个额外的方法重构的方式 。
使用比例字体。
我是认真的。 我通常可以在不牺牲可读性或可印刷性的情况下，将一行中的100-120个字符对等。 事实上，使用良好的字体（例如Verdana）和语法着色来阅读更为容易。 这几天看起来有点奇怪，但你很快就习惯了。
作为我的雇主的编码指南的作者，我把行长从80增加到132.为什么这个值呢？ 那么像其他人指出的那样， 80是许多旧硬件terminal的长度。 而且132也是！ 这是terminal处于宽屏模式时的线宽。 任何打印机也可以使用浓缩字体在宽模式下制作硬拷贝。
不停留在80的原因是我宁愿
- 更喜欢更长的名称和标识符的含义
- 不用打扰typedefs结构和枚举在C（他们是坏的，他们隐藏有用的信息！如果你不相信，请问彼得范德林登在“深C秘密”），所以代码有更多的
struct FOO func(struct BAR *aWhatever, ...)比typedef狂热分子的代码。
根据这些规则，只有80个字符/行比我的眼睛看起来更可以接受（主要是原型和函数定义）。
我不强制80个字符意味着最终换行。
国际海事组织，任何长度select一个最大宽度线并不总是适当的，换行应是一个可能的答案。
这并不像听起来那么容易。
它是用jedit 替代文字http://www.jedit.orghttp://img.dovov.comlogo64.png实现的，它提供了自动换行;
但是从一个月亮的时间里，它在日食中被错过 ！ （事实上从2003年起），主要是因为文字编辑器的一个换行包括：
- 包装线信息是用于文本查看器，代码导航，垂直标尺。
- 打开的行信息是必要的function，如goto行，行号标尺列，当前行高亮，保存文件。
我试图把东西放在80个字符之内，原因很简单：太多了，意味着我的代码变得太复杂了。 过于冗长的属性/方法名称，类名等等会造成与简洁的一样多的伤害。
我主要是一个Python编码器，所以这产生了两套限制：
- 不要写很长的代码
- 不要缩进太多
当你开始达到两到三个缩进级别时，你的逻辑会变得混乱。 如果你不能在同一个页面上保留一个块，你的代码变得太复杂，难以记忆。 如果你不能保持在80个字符以内的单行，你的线越来越复杂。
在Python中编写相对简洁的代码非常容易（请参阅codegolf），代价是可读性，但是编写冗长的代码更易于阅读。 辅助方法不是一件坏事，辅助类也不是。 过度的抽象可能是一个问题，但这是编程的另一个挑战。
如果不确定，像C这样的语言编写助手函数，并且如果你不想调用另一个函数并跳回去的开销，就内联它们。 在大多数情况下，编译器会为您智能地处理事情。
已经有很多很好的答案了，但是值得一提的是，在你的IDE中你可能有一个左边的文件列表，右边的列表（或者其他configuration）。
你的代码只是环境的一部分。
我实际上遵循类似的规则为我自己的代码，但只是因为打印代码到一个A4页 – 80列是我所需的字体大小正确的宽度。
但这是个人偏好，可能不是你以前的样子（因为你想要弹药去其他方式）。
你不质疑背后的推理吗？严重的是，如果没有人能够拿出一个很好的理由，那么你有一个很好的理由把它从你的编码标准中删除。
我一天比一天差，我没有一个怪胎'22英寸显示器。 我不知道我会不会。 当然，这对于只使用箭头编码和300个字符的只写程序员是没有兴趣的。
是的，因为即使在这个时代，我们中的一些人在terminal上编码（好的，主要是terminal仿真器），其中显示器只能显示80个字符。 所以，至less对于我所做的编码，我真的很欣赏80字符规则。
我仍然认为这个限制在视觉上是不受限制的。 当然，显示器和分辨率足够大，可以显示出更多的字符，但它是否增加了可读性？
如果这个限制真的被强制执行，那么重新考虑代码而不是把所有东西都放在一行中也是一个很好的理由。 缩进也是如此 – 如果需要更多级别的代码，需要重新考虑。
打破80个字符是你在编码时做的事情， 而不是事后。 当然，和评论一样。 大多数编辑可以帮助您查看80个字符的限制。
（这可能有点OT，但是在Eclipse中有一个选项可以在你保存的时候对代码进行格式化（根据你想要的任何规则），起初有点怪异，但是一段时间后你开始接受格式化不在您的手中，而不是生成的代码。）
如果我们有其中一个，我们就不会有这个讨论！ 😉
但是，认真回答人们提出的问题是相当合理的。 然而，原来的海报并不是争论不休，只有80列是太less了。
电子邮件代码片段的问题有一些好处。 但考虑到大多数电子邮件客户端对格式化文本进行的恶意操作，我认为换行只是您的一个问题。
至于印刷方面，我通常会发现100个字符线会非常舒适地贴在印刷页面上。
我尝试保持我的行低于80列。 最强的原因是我经常在命令行工作时发现自己使用grep而less浏览我的代码。 我真的不喜欢terminal如何打破长时间的源代码（他们毕竟不是为了这个工作）。 另一个原因是，如果一切都符合要求并且不被编辑打破，我觉得它看起来更好。 例如长函数调用的参数很好地彼此alignment和类似的东西。
