在宽屏显示器时,80个字符的限制仍然有用吗?[关闭]


56

在宽屏显示器上,一次无需滚动条即可轻松看到80个以上的字符。甚至连linus torvalds都认为80个字符的限制已经过时了

因此,在宽屏显示器时代,80个字符的限制仍然有用吗?


1
有很好的理由在Eclipse中使行短。这使您可以在普通打印机上以可读字体打印程序,而无需换行。

在什么情况下?如果您在特定的编程环境中提问,我将投票决定重新开放。
妮可


Visual Studio的自动换行已损坏,因此大多数用户都没有使用它。相反,他们手动插入换行符。对于使用不同屏幕宽度的任何人来说,这看起来都很糟糕。visualstudio.uservoice.com/forums/121579-visual-studio/...
上校恐慌

Answers:


28

仍然有80个字符限制的原因有很多(或者74个字符限制更好);即使您添加了diff标记和电子邮件引号,它也允许代码保持少于80列。邮件列表)。

即使在宽屏显示器时代,我也希望并排打开多个窗口,以显示代码的不同部分。例如,我通常在一个屏幕上打开一个网络浏览器和电子邮件,在另一个监视器上同时打开两个文件和一个终端。如果行数超过80列,则需要处理将行换行的编辑器(这很丑陋,使代码难以导航),或者加宽窗口,以至于无法容纳一旦。

即使您通常不以这种方式进行编辑,但如果您使用并排的diff工具,您也会欣赏具有合理行长的文件,这将使您的diff易于查看。

还有一个代码密度问题。阅读代码时,我喜欢有很多上下文。上下滚动窗口比滚动滚动要快得多。如果行很长,那么行的长度也往往相差很大,这会浪费大量屏幕空间,并且在给定时间总体上只能容纳较少的代码。

最后,如果您的行很长,那通常意味着您的行很复杂,内容很深,或者标识符很长。所有这些都是一个问题。复杂的行可能做得太多;如果您可以将其分解为几个简单的行,则可能应该这样做。深度缩进意味着您可能嵌套了太多的循环和条件,这会使您的代码流混乱;考虑将其重构为几个功能。而且,如果您的标识符太长,可能会使读取代码非常困难。人们通常将单词视为单个单位。他们不会一一阅读每个字符,而是查看单词的整体形状。长标识符很难通过这种方式进行区分,通常,如果长标识符那么长,它们将包含冗余或重复信息。

现在,虽然将代码保持在80列以下仍是一种很好的做法,但这并不是必须认真遵循的规则之一,而如果不这样做,就会扭曲自己以使其适合某些行。我建议您尝试将所有代码保持在80列以下,但是当它不合适时,请不要担心太多。


3
同意 但是,有时会鼓励使用长标识符(通过编码准则(例如“使用有意义的名称”或“避免使用隐喻的缩写”))或必要的标识符(例如std::vector<...>::const_iterator),尽管在后一种情况下,通常可以通过typedef来缓解。
musiphil

很好的理由。只要您的团队(或邮件列表?)同意,我不确定确切的行长是否重要。就我个人而言,我接受鲍伯叔叔的建议,即不要超过120个字符。
艾伦

1
@musiphil是的,这就是为什么我包括了最后一段。我在C ++中碰到过几行,在声明该方法时,我根本无法将类名,方法名和返回类型放在80列的行中。与其做一些真正奇怪的换行,不如打破该行的80列(或100列)规则。
布莱恩·坎贝尔

46

如果我的行数少于100个字符,则可以在宽屏显示器上并排放置两个编辑器窗口。同时使类头文件和实现都可见,或者一侧有代码调用另一侧的代码,这是非常有用的。而且,如果我使行短,则我的编辑器窗口上不需要水平滚动条,这给了我更多的垂直空间。

80个字符可能已过时,但是将内容保持在合理范围内还有一些优点。


1
+1,我经常在Vim或其他编辑器中并排打开多个源文件。使用足够小的字体和相当窄的右边界,我可以非常快速地获得项目的概述,甚至打开大量文档。
greyfade 2010年

4
80个字符仍然很重要,因为许多人默认使用其终端和编辑器那么宽。因此,如果您将自己限制为80岁,您将对这些人友好,而不是要求他们重新排列所有窗口或处理换行或水平滚动。
Brian Campbell 2010年

1
80个字符仍然合理;比这更长的时间会鼓励过度嵌套的代码(而不是重构!),并排放置多个窗口非常有用。添加另一个监视器只会增加您一次可以看到的窗口数量!
Donal Fellows,

1
80也许对VMS友好。请原谅我的新时代的思维,但我们也应该尽可能延长限制,并保持它在必要时..
罗斯

29

我认为显示器与它没有任何关系-至少现在不再如此。

如果您不能用80个字符编写一行代码,那么无论如何这可能是错误代码的标志。表达式太复杂。压痕太深。等等。你应该停下来,重新思考自己在做什么。

但是,如果您确定代码需要80行以上,请继续执行。我认为拥有超过80个字符的代码比添加惯用的更改以使其更小更好。

我个人讨厌这种东西:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

而不是简单地:

ret = my_function(parameter1, parameter2, parameter3, parameter4);

5
当然,如果第一个示例中的第3行不太长,则第2行可以合并为第1行,这使它看起来更具可读性。(哪种语言要求在括号内使用转义的换行符?)

1
啊,那只是我写的一些伪代码。但是我认为C需要它。
Cesar Canassa 2010年

4
仅在(或应该是)罕见的多行宏定义中。它极大地影响了最大行长的选择(保持这样的反斜杠不好玩),所以我很好奇为什么要显示它。好像是个稻草人

2
如果我在函数调用中遇到断行的麻烦,我会将每个参数放在自己的行上,以一个级别缩进。
starblue 2010年

20

要编码?

当然可以。普通人读得不太宽。用很少的柱子,您的眼睛移动会更少,您可以更好地聚焦并延迟疲劳。这是最小的收益,但很重要。


3
虽然我觉得代码与散文有很大的不同,但是读取定期(即散文通常会更加一致)将行延伸到120列以上的代码很累。

6

是的,有一些限制代码行长度的原因:

  1. 尽管我们的屏幕越来越宽,但有时您仍需要打印代码。如果仅仅是因为这个原因
  2. 差异查看器通常会显示垂直分割的线-如果这些线的宽度与宽屏所允许的长度相同,则会变得更加困难。

话虽如此,80太少了。但是,作为设计原则,某些限制可能仍然是一个好主意。

我会说,不应该禁止多余的长行,因为偶尔必要。但是,如果大多数功能只能在30英寸的屏幕上查看,则代码会有一些问题。


5

它是任意的,但是对易读内容没有任何限制。我发现,无论是代码还是散文,文本的超宽列都很难扫描和阅读。此外,正如许多其他答案所指出的那样,该代码并不是唯一出现在屏幕上的东西。同时具有两个或多个代码窗口,并将它们放在一个宽屏显示器上,这是很棒的。


3

确切地选择80个字符的限制可能无关紧要;例如,如果限制为85,将会发生什么变化?

确实,当今使用的监视器具有更高的分辨率,但是在文本编辑器/ IDE中,并非所有空间都来自文本视图;在我使用的编辑器中,左侧显示了项目中包含的文件列表。

上网本或笔记本电脑使用的分辨率与显示器使用的分辨率不同。使用不对任何人产生“问题”的字符限制可能是有意义的。


5
80个字符是打孔卡上列数的硬性限制!
克里斯·

5
标准是什么都没有关系,但是如果每个人都遵循相同的标准,那么它将使生活变得更轻松。
Skilldrick 2010年

2

这确实取决于开发环境。

例如,在一个拥有数千名开发人员的大型公司中,可能会有数百人在产品的整个生命周期中不得不查看其代码的某些部分。有了这么多人,由于某种原因(旧硬件,上网本等),肯定会有少数人以800x600或更小尺寸运行。容纳它们有一些价值。

但是,在我有25名员工的公司中,我说​​要拧螺丝。我们都在使用最大分辨率为120-140左右的双显示器,这是非正式指南。


2

有一些限制当然是有道理的。但是80个字符的限制太过限制了。我更喜欢96个字符的限制。它足以处理我要处理的大多数代码,而且也足够狭窄,因此可以并排放置两个文件以进行比较(在宽屏幕上)。

我相信代码的可读性胜过其他所有问题。每行96个字符的代码比80行更具可读性。

我不赞成大多数人将终端设置为80个字符宽的说法,也不认为打印机必须换行超过80个字符的行。这不是硬性限制,因为它曾经是(遥远的)过去。您可以轻松地将终端和打印机宽度设置为100个字符。


1

不,它不再相关:

  • 无论如何,应用程序和网络上使用的大多数字体都不是固定宽度的。换句话说,80个字符!= 80个字符。
  • 如您所说,屏幕宽度已更改-80个字符不是明智的界限。

80个字符实际上是在控制台环境中使用固定宽度字体的准则。

当然,如果您仍在控制台环境中使用固定宽度的字体...那么可以肯定,80个字符是明智的:)


3
我敢肯定,他指的是在源代码中使用80个字符的限制,该限制几乎普遍以等宽字体显示。
Fishtoaster

1
嗯...在那种情况下...仍然没有,但由于其他原因:)
Damovisa 2010年

1
80个字符是打孔卡上列数的硬性限制!
克里斯·

0

如果在GUI中使用编辑器,则每行80个字符是无关紧要的,因为大多数体面的编辑器(例如Notepad ++)都有用于切换换行的按钮。这样,即使在薄窗口中查看代码也不会有问题。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.