我编写并喜欢适合curl和其他项目中80列的代码，这是有原因的。我对那些回答并说他们已经拥有400英寸显示器并且可以使用它们的人感到无聊。
我也有多个大型高分辨率屏幕，但是编写宽代码仍然不是一个好主意！因此，我决定一劳永逸地写下我的理由！
几个世纪以来，报纸和杂志使用窄文字是有原因的，实际上甚至书籍都没有使用长行。对于大多数人来说，在眼睛和大脑上阅读不使用很长线条的文字更容易。这已经很长时间了。
易于阅读的代码易于遵循和理解，从而减少了错误并加快了调试速度。
除了看电影外，我从不在屏幕上运行任何大小的窗口。我经常彼此相邻有两个或多个编辑器窗口，有时在它们旁边还具有一个或两个额外的终端/调试器窗口。为了使其可行并仍然使代码可读，它需要在这些窗口中“无包装”。
有时并排读取代码差异比较容易，然后使两者能够很好地彼此相邻也很重要。
使代码垂直而不是水平增长对于diff，git和其他处理文件更改的工具是有益的。它减少了合并冲突的风险，并使合并冲突仍然易于处理。
严格禁止在列80之外添加任何内容的副作用是，要在函数和标识符上使用那些令人讨厌的30多个字母Java样式名称确实变得非常困难。函数名称（尤其是本地名称）应该简短。长名称使它们确实很难阅读，也很难发现具有类似长名称的其他功能之间的区别，其中仅更改了其中的一个子词。
我知道特别是Java人士反对这一点，因为他们是在不同的文化中接受培训的，他们说方法名称应该包括许多功能的“帮助用户”细节，但是对我来说，这是一个很弱的论点，因为所有-平凡的功能将具有比名称中所表达的功能更多的功能，因此用户需要了解该功能的工作方式。
为了使这项工作有效，并且允许一些缩进级别，代码基本上必须具有较小的缩进级别，因此我更喜欢将其设置为每个级别两个空格。
如果您执行许多缩进级别，那么编写仍然适合80列限制的代码将变得非常困难。这是建议您不要编写需要或使用那么多缩进级别的函数的巧妙方法。然后，应将其拆分为多个较小的功能，然后每个功能将不需要那么多个级别！
很久以前，当然是因为终端有这个限制，而如今，确切的数字80并不是必须的。我只是碰巧认为该限制在过去一直运作良好，此后我再也没有发现任何有力的理由对其进行更改。
它也必须是一个固定的硬限制，就像我们允许几个地方超出限制一样，我们最终会在一个滑坡上结束，并且代码会随着时间的推移逐渐变宽–我已经看到，在许多具有“软执行”功能的项目中， ”上的代码列限制。
在curl中，我们有一个“ checksrc”，它会向任何试图构建存在太长行的代码的用户大喊错误。这样做很好，因为这样我们就不必浪费人力来向提出请求的贡献者指出这一点。该工具将无情地指出此类错误。