编写源代码时如何遵循80个字符限制的最佳做法?


15

如您所知,有一个最佳做法是

一行源代码限制为80个字符。

这里有2个链接:

为什么80个字符是代码宽度的“标准”限制?

在宽屏显示器时,80个字符的限制是否仍然有用?

而且,我敢肯定,如果您搜索此最佳做法,可以做得更好。

但是我发现这非常困难,这是一个示例示例:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference

因此,您可以缩进每个类,每个方法和每个语句。

在“ myReference”中最后一个“ e”的结尾,我已经在第60列了。

我还有20个空格,实际上是要调用构造函数并将对象分配给我拥有的引用。

我的意思是,这看起来真的更好吗:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference 
                = new HashMap<String, List<MyInterfaceHere>>(); 

最佳做法是什么?


6
我们将其
设为

7
最好的做法,除非你是在结束生命的版本像5/6可能会是final Map<String, List<MyInterfaceHere>> myReference = new HashMap<>();(80个字符与缩进,如在你的例子)
蚊蚋

4
最佳实践是不要盲目使用20年前的最佳实践。当17英寸CRT的分辨率为1280x1024时,可以使用较低的字符数限制,但今天还没有
。– TMN

2
请注意,使用文本的窄列而不是散布在显示器的所有可用空间中的一个好处是能够轻松地并排查看多个代码段。80 chars * 7 pixels/char = 560 pixels per file。这使两个文件(1120 px)可以舒适地适合1280 px宽的屏幕,或者三个(1680 px)可以适合1920 px的屏幕,在两种情况下都为行号,滚动条,信号线和其他UI元素保留了一些额外的空间。 。甚至偶尔会稍长一些。
8bittree '16

3
@ 8bittree我可以在两个监视器上并排查看代码。在单个监视器上进行开发就像在开车时只用一个方向盘。

Answers:


18

最佳实践应该是“限制行的长度,以便您,您的所有同事以及您使用的所有工具都满意”,以及一些常识。80个字符似乎非常低,并且倾向于降低可读性。我曾经被这样的一句话完全欺骗:

/* Very long comment to the end of the line */ realCode ();

在屏幕上看不到函数调用(任何同事的屏幕上都不可见)的地方,没有任何指示。

我将编辑器设置为显示100列的页边距,并重新包装了显示的代码,因此在编辑时所有内容始终可见,并且过长的行倾向于手动拆分为两行或更多行。祈求您的编辑器可以很好地格式化拆分语句,如果它可以自动格式化的话。使用不会导致深层嵌套的语句的编码样式。(有些人创建了一个包含二十个if语句的嵌套,然后创建了二十个if语句的尾部,从而导致200个字符的深缩进,而没人能弄清楚哪个if语句属于哪个)。

在您的特定情况下,Swift发明了一种避免这种情况的方法:“ let”变量(与其他语言的“ final”变量几乎相同)必须在使用前精确分配一次值,但不一定要在声明中使用,因此您可以将麻烦的行分成两个独立的语句。

PS。我遇到了用人工代码编写的超过400个字符的行。换句话说,即使在24英寸显示器上,您也需要滚动阅读才能阅读其余内容。我没被逗乐:-(


10
似乎/* Very long comment to the end of the line */ realCode ();应该已经打破了其他一些样式规则。
罗伯特·哈维

3
/* Very long comment to the end of the line */ realCode ();这是IDE具有代码格式化程序的原因之一,该代码格式化程序会自动将注释和代码放在单独的行中。

2
它来自臭名昭著的“ if(condition)\ n \ tgoto exit; \ n \ tgoto exit;”。就在几年前。
gnasher729 '16

我发现将最大行长设置为80个字符会迫使我根据功能和类以及OO进行思考,而不是编写一长行文本来一次完成所有操作。它使我编写了其他人可以轻松准备的程序。其次,大多数编程人员(以我的经验)我在SV的笔记本电脑上工作时都看到过,并且没有一直在使用大屏幕显示器。因此,使用80个字符的行数限制对所有人都有帮助。第三,您可以将大型监视器屏幕划分为多个窗格,并同时查看代码。
alpha_989 '18

3

是的,看起来确实更好。这就是为什么“不要使用超长线!” 格言非常强烈。

至于最佳实践,我从不使用这些可怕的长构造函数表达式。我会一直使用

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> yReference = newMap();

对于的一些适当定义的静态导入值newMap()。我认为这是Java的一个严重缺陷,因为它没有内置版本。


1

目标不是“保持每行80个字符”。目标是“使代码易于阅读和理解”。人为的80个字符限制有助于提高可读性,但是除非您的团队认为是这样,否则这不是一个一成不变的规则。

您要求最佳实践,而最佳实践是“专注于使代码尽可能可读”。如果那需要超过80个字符,那就这样吧。


1

不要害怕按回车键。大多数现代语言(例如您的示例中包括Java)对跨几行的语句都非常满意。

只需稍微思考一下您在哪里打破界限,就可以得到符合80列限制的内容,并且仍然保持可读性。官方Java编码约定甚至指定了换行的首选位置。

正确的做法是,将一条整齐的折线比从屏幕侧面消失的折线可读性强得多。


1

如果您强制执行代码的行长/宽度,请使用工具。

  • 收割者
  • 视觉辅助
  • 等等

开发人员确定合理的长度(80、120、200等),然后在工具中设置该选项。

之后,只需按照通常的方式编写代码,而无需考虑行的宽度或长度。运行正常并完成后,右键单击并选择清理代码或类似选项。该工具将按照您的指示设置代码格式,并按照指示拆分长行。

简单易用,每个源文件的格式都相同。


0

这些天80个字符的限制可能太短了,但这很有帮助。我同意所有这些意见,即代码也应格式正确。例如代码

/ *在该行末尾的注释很长* / realCode();

可能在80个小时之内,但由于注释和代码选项在同一行上而造成混乱。

遵守或不遵守80赫兹的限制是个人的选择,但如果单眼可见,则程序员和其他审阅者也将始终享有舒适的视野。

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.