是否有正当理由在当今这个年龄段的代码文件中强制使用80个字符的最大宽度？[关闭]
Answers:
我认为将代码保持在80（或79）列的做法最初是为了支持人们在80列哑终端或80列打印输出上编辑代码。这些要求现在大部分已经消失了，但是仍然有合理的理由保留80列规则：
- 为了避免在将代码复制到电子邮件，网页和书籍中时进行换行。
- 并排或使用并排的diff查看器来查看多个源窗口。
- 提高可读性。可以快速读取狭窄的代码，而无需从一侧到另一侧扫描眼睛。
我认为最后一点是最重要的。尽管最近几年显示器的尺寸和分辨率有所增长，但眼睛却没有。
您应该这样做是为了没有22英寸宽屏显示器的每个人。就个人而言，我在17英寸4：3显示器上工作，发现它足够宽。但是，我也有3个这样的显示器，所以我仍然有很多可用的屏幕空间。
不仅如此，如果行太长，人眼实际上在阅读文本时也会遇到问题。迷失在哪条线上太容易了。报纸的宽度为17英寸（或类似的东西），但您看不到它们在页面上始终书写，杂志和其他印刷品也是如此。如果您将列保持狭窄，则实际上更容易阅读。
如果您有一系列重复但有一些细微差异的语句，那么将这些相似性和差异分组为几行以使差异垂直对齐，则可以更轻松地看到它们。
我认为以下内容比如果将其分成多行的可读性要强得多：
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列，但我认为我的观点仍然成立，我只是举了一个不好的例子。它仍然表明在一行上放置多个语句可以提高可读性。
(ctrl+)arrow超过或打end
超长线很难阅读。仅仅因为您可以在显示器上显示300个字符，并不意味着您应该使行长。除非您别无选择（调用需要一堆参数），否则300个字符的语句也太复杂了。
我通常使用80个字符，但如果执行此命令，我将超越此限制，这意味着将换行符放置在不希望的位置。
我唯一要保留在80个字符以内的是我的评论。
就个人而言...我将所有的脑力（几乎没有）都投入到正确的编码上，当我可能将时间花在下一个功能上时，不得不回过头来将所有内容分解为80个字符的限制是很痛苦的。是的，我想Resharper可以为我做这件事，但是这让我有些惊讶，因为第三方产品正在决定我的代码布局并更改它（“请不要将我的代码分成两行HAL。HAL？” ）。
就是说，我确实在一个很小的团队中工作，并且我们所有的监视器都很大，所以就目前而言，担心让我的程序员感到困扰的问题并不是什么大问题。
似乎有些语言会鼓励使用更长的代码行，以便提高成本（如果then语句，则简明扼要）。
我有两个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”字体。
人们说长行代码往往很复杂。考虑一个简单的Java类：
public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {
这是94个字符的长度，并且类名非常短（根据GWT标准）。很难在两行上阅读，并且在一行上可读性强。出于实用性考虑，因此允许“向后兼容”，我想说100个字符是正确的宽度。
您不是唯一要维护您的代码的人。
下一个这样做的人可能有17英寸的屏幕，或者可能需要大字体才能阅读文本。由于以前的屏幕限制，此限制必须在某个地方，并且惯例为80个字符。您能想到任何新的标准（120）和为什么最好使用其他字体，而不是“这就是我的显示器以Xpt字体显示的字体？”
请记住，每条规则总是有例外，因此您有特定的一行或一段代码，有意义的是超过80个字符，然后成为叛逆者。
但是，花点时间先思考一下“这段代码真的很糟糕，以致不能容纳80个字符吗？”
在Linux编码标准中，它们不仅保留80个字符的限制，而且还使用8个空格的缩进。
部分原因是，如果您达到正确的边距，则应考虑将缩进级别移至单独的函数中。
这将使代码更清晰，因为无论缩进长度如何，都很难读取具有许多嵌套控制结构的代码。
我已经将代码扩展到100个字符，可以舒适地放入不到Macbook屏幕一半的位置。行开始变得太长和太复杂之前，可能限制为120个字符。您不想太宽泛，否则会鼓励复合语句和深度嵌套的控制结构。
正确的余量是自然界告诉您执行额外的方法重构的方式。
作为我雇主的编码准则的作者，我已将行长度从80增加到132。为什么要使用此值？好吧，就像其他人指出的那样，80是许多旧硬件终端的长度。132也是！端子处于宽屏模式时的线宽。任何打印机还可以使用压缩字体在宽屏模式下进行硬拷贝。
不留在80岁的原因是我宁愿
- 希望使用较长的名称，并带有标识符的含义
- 不用为C中的结构和枚举而烦恼typedef（它们是错误的，它们会隐藏有用的信息！如果您不相信，请在“ Deep C Secrets”中询问Peter van der Linden），因此该代码
struct FOO func(struct BAR *aWhatever, ...)不仅仅是typedef狂热者的代码。
在这些规则下，仅80个字符/行会导致丑陋的换行次数超出我的眼睛的接受范围（通常是在原型和函数定义中）。
使用比例字体。
我是认真的。通常，在不牺牲可读性或可打印性的情况下，我通常可以在一行中获得100-120个字符。实际上，使用好的字体（例如Verdana）和语法着色甚至更容易阅读。几天后看起来有些奇怪，但是您很快就习惯了。
我试图将内容限制在80个字符以内的原因很简单：太多了，这意味着我的代码变得太复杂了。过于冗长的属性/方法名称，类名称等造成的危害与简洁的危害相同。
我主要是Python编码器，因此这产生了两组限制：
- 不要写很长的代码
- 不要缩进太多
当您开始达到两个或三个缩进级别时，您的逻辑就会变得混乱。如果您无法在同一页面上保留单个块，则您的代码将变得太复杂且难以记住。如果您不能在80个字符内保留一行，那么您的行就会变得过于复杂。
在Python中，以可读性为代价编写相对简洁的代码（请参见codegolf）很容易，但是以可读性为代价编写冗长的代码甚至更容易。辅助方法不是一件坏事，辅助类也不是坏事。过多的抽象可能是一个问题，但这是编程的另一个挑战。
如果对C之类的语言有疑问，请编写辅助函数并将其内联，如果您不希望调用另一个函数并跳回的开销。在大多数情况下，编译器将为您智能地处理事情。
对于我自己的代码，我实际上遵循类似的规则，但仅是因为将代码打印到A4页面上-80列大约适合于所需字体大小的宽度。
但这是个人喜好，可能不是您追求的（因为您希望弹药走另一条路）。
您不质疑限制背后的原因-严重的是，如果没有人能提出这样一个充分的理由，那么您有很好的理由将其从编码标准中删除。
如果我们有一个这些，我们就不会有这个讨论！;-)
但是，认真地说，人们在回答中提出的问题是完全合理的。但是，最初的张贴者并没有争论极限，只是80列太少了。
通过电子邮件发送代码段的问题有一些好处。但是考虑到大多数电子邮件客户端对预格式化文本所做的邪恶行为，我认为换行只是您的问题之一。
对于打印，我通常发现100个字符行将非常舒适地适合打印页面。
我尝试将行数保持在80列以下。最主要的原因是，在命令行工作时，我经常发现自己正在使用grep和less浏览代码。我真的不喜欢终端如何中断长的源代码行（毕竟，这些源代码不是用于该工作的）。另一个原因是，我发现如果所有内容都适合该行并且未被编辑器破坏，它看起来会更好。例如，具有长函数调用的参数在彼此之间和相似的东西之间很好地对齐。