在当今这个时代，对代码文件强制限制最大宽度为80个字符有合理的理由吗？

其他回答已经总结得很好了，但也值得考虑什么时候需要将一些代码复制粘贴到电子邮件中，或者如果不是代码，则需要进行差异比较。这就是“最大宽度”有用的时候。

我有两个20英寸的1600x1200显示器，我坚持使用80列，因为它让我能够并排显示多个文本编辑器窗口。使用“6x13”字体（传统的xterm字体），80列占用480个像素加上滚动条和窗口边框。这允许在1600x1200的监视器上拥有三个此类型的窗口。在Windows中，Lucida Console字体不能完全达到此效果（最小可用尺寸为7像素），但是1280x1024的显示器将显示两列，而1920x1200像HP LP2465这样的显示器将显示3列。它还会在Visual Studio的各种资源管理器、属性窗口和其他窗口旁留出一些空间。
此外，过长的文本行很难阅读。对于文本，最佳长度为66个字符。有一个临界点，过长的标识符会产生反作用，因为它们使代码排版变得困难。良好的布局和缩进提供了关于代码结构的视觉提示，某些语言（例如Python）明确使用缩进来实现此目的。
然而，Java和.Net的标准类库往往有很多非常长的标识符，因此不能保证一定能够做到这一点。在这种情况下，使用换行排版代码仍有助于使结构明确。
请注意，您可以在此处获取“6x13”字体的Windows版本。

人们常说代码行数越长，就越复杂。考虑一个简单的Java类：

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

这段文字有94个字符，类名相对于GWT标准来说较短。如果在两行上阅读将会很困难，而一行则更易读。 实际上，考虑到"向后兼容"的实际情况，我认为100个字符的宽度是比较合适的。

作为雇主编码指南的作者，我将行宽从80增加到132。为什么是132？像其他人指出的那样，80是许多旧硬件终端的长度。而132也是！这是终端处于宽模式下的行宽。任何打印机也可以使用紧凑字体在宽模式下生成硬拷贝。
不保持在80的原因是我更喜欢使用有意义的较长名称作为标识符，并且不想在C中为结构体和枚举类型定义typedef（它们很糟糕，会隐藏有用信息！如果您不相信，请问Peter van der Linden在“Deep C Secrets”中），因此代码中有更多的`struct FOO func(struct BAR *aWhatever, ...)`而不是typedef迷的代码。
根据这些规则，只有80个字符/行会导致丑陋的换行符比我的眼睛认为可接受的情况更频繁（主要是在原型和函数定义中）。

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

下一个维护者可能有一台17英寸的屏幕，或者需要放大字体来阅读文本。限制必须存在，80个字符是因为先前的屏幕限制而形成的惯例。你能想到任何新的标准（120），并说明除了“这适合我的Xpt字体监视器外”，使用它的好处是什么吗？

记住，每条规则总会有例外，所以如果您有特定的行或代码块需要超过80个字符，则可以打破规则。

但首先要想一想，“这段代码真的不能在80个字符内完成吗？”

我已将代码宽度扩展到100个字符，这在我的Macbook屏幕上舒适地占据了不到一半的空间。 120个字符可能是极限，否则行就会变得太长和复杂。您不想让宽度过大，因为这会鼓励复合语句和嵌套控制结构。

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

我想知道是否在今天这个时代会导致更多问题。请记住，在C语言（和可能其他语言中）有关于函数名长度的规定。因此，你经常会看到在C代码中很难理解的名称。好处是它们不占用太多的空间。但是每当我查看像C#或Java这样的语言中的代码时，方法名称通常非常长，这使得将代码保持在80个字符长度几乎不可能。我认为80个字符对于今天来说并不合适，除非你需要能够打印代码等。

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

我喜欢将文本宽度限制在100个字符左右，这样可以在宽屏幕监视器上使用两个并排编辑器。我认为现在没有必要严格限制文本宽度为80个字符。

使用比例字体。

我很认真。通常情况下，我可以在不影响可读性或可打印性的情况下获得每行100-120个字符的等效值。事实上，在使用良好的字体（例如Verdana）和语法着色的情况下，阅读起来甚至更容易。一开始可能看起来有点奇怪，但你很快就会习惯。