JavaScript的编码规范:在括号之间使用空格

9
根据JSHint,Javascript程序员在第一个括号之后和最后一个括号之前不应添加空格。
我看过很多优秀的Javascript库都添加了空格,如下所示:
( foo === bar )  // bad according to JSHint 

不要这样做:

(foo === bar)   // good according to JSHint 

说实话,我更喜欢第一种方式(更多空格),因为它使代码更易读。是否有强烈的理由偏爱第二种方式,这也是JSHint推荐的方式?

8个回答

16
这是我的个人偏好,并附上原因。
我将在接受的答案中讨论以下项目,但顺序相反。
注意一:并非针对Alnitak,这些评论适用于我们所有人...
注意二:代码示例不以代码块形式编写,因为语法高亮会分散对仅限于空格的实际问题的关注。
我总是这样做。
这不仅从来不是捍卫编程实践的好理由,而且从来不是捍卫反对变革的任何想法的好理由。
JS文件下载大小很重要[尽管缩小当然可以解决这个问题]
对于将要通过网络发送的任何文件,大小始终很重要,这就是为什么我们有缩小来去除不必要的空格。由于JS文件现在可以减小,因此生产代码中空格的争论已经没有意义了。
无实际价值或意义;纯学术的。moot definition 现在我们来谈谈这个问题的核心。以下想法只属于我个人,我知道可能会引起争议。我并不声称这种做法是正确的,只是在目前对我来说是正确的。如果已经有充分证明这个想法是错误的,我愿意讨论替代方案。

它非常易读,并且遵循JavaScript祖先语言中绝大部分格式约定。

这个声明有两个部分:“它非常易读;”,“并且遵循JavaScript祖先语言中绝大部分格式约定”。
第二部分可以归结为“我一直都是这样做的”这种想法。
所以让我们专注于声明的第一部分:“它非常易读。”
首先,让我们就代码本身做出几个声明。
  1. 编程语言不是为计算机阅读,而是为人们阅读
  2. 在英语中,我们从左到右,从上到下阅读
  3. 遵循英语语法中已经确立的规范,将使更多使用英文编码的程序员更容易阅读代码

注意:我仅就英语语言进行论述,但可能适用于许多拉丁语系语言。

通过删除副词perfectly,我们可以缩小第一句话的范围,因为它暗示了没有改进的空间。相反,我们应该关注留下来的内容:"它是可读的"。事实上,我们可以使用JS创建一个变量:"isReadable"作为布尔值。

问题

这个问题提供了两个选择:

( foo === bar )

(foo === bar)

缺乏上下文,我们可以偏向于英语语法,选择第二个选项,去除空格。然而,在这两种情况下,“isReadable”都很容易是 true 。因此,让我们进一步去除所有空格...
(foo===bar)

我们还能声称 isReadable 是真的吗?这里布尔值可能不适用于所有情况。让我们将isReadable移动到Float,其中0不可读1完全可读
在前面的三个例子中,我们可以假设我们会得到一个从0-1的值集合,每个单独的例子都是从我们问的每个人那里得到的:"在0-1的范围内,您如何评价此文本的可读性?"
现在让我们给这些例子加上一些JS上下文...
  1. if ( foo === bar ) { } ;
  2. if(foo === bar){};
  3. if(foo===bar){};
同样,在这里我们的问题是:"在0-1的范围内,您如何评价此文本的可读性?"
我在这里做出假设,即空格有一个平衡点:太少的空格使isReadable接近0;太多的空格使isReadable接近0。

例子:"Howareyou?" 和 "How are you ?"

如果我们在许多 JS 示例后继续问这个问题,我们可能会发现可接受空格的平均限制,这可能接近英语语法规则。

但首先,让我们继续讨论 JS 中括号的另一个例子:函数!

function isReadable(one, two, three){};

function examineString(string){};

以下是两个函数示例,遵循当前标准,在()之间没有空格,除非在逗号后面。下面的下一个参数与如上所示声明函数时如何使用空格无关,而是代码可读性最重要的部分:代码被调用的位置!
针对下面的每个示例,提出以下问题...
“在0-1的评分中,您会如何评价此文本的可读性?”
  1. examineString(isReadable(string));

  2. examineString( isReadable( string ));

第二个示例使用了我自己的规则
1.单词之间的括号之间有空格,但开放或关闭标点符号之间没有空格。 即不像这样examineString( isReadable( string ) ) ; 但像这样examineString( isReadable( string )); 或者这样examineString( isReadable({ string: string, thing: thing }); 如果我们使用英语语法规则,那么我们会在“(”前加上空格,我们的代码将是...
examineString (isReadable (string));

我不赞同这种做法,因为它将函数调用与函数本身分开,而它们应该是相互关联的一部分。
examineString(); // yes; examineString (): // no;

既然我们并不完全遵循英语语法, 但英语语法确实要求断开, 那么在括号之间添加空格或许可以让我们更接近1, 从而达到更易读的效果?

我会把这个问题留给你们, 但请记住基本问题:

"这个改变让它更易读还是更难读?"

这里有一些例子来支持我的观点.

假设函数和变量已经被声明...

input.$setViewValue(setToUpperLimit(inputValue));

这样写是一个正确的英语句子吗?

input.$setViewValue( setToUpperLimit( inputValue ));

更接近1?

config.urls['pay-me-now'].initialize(filterSomeValues).then(magic);

或者

config.urls[ 'pay-me-now' ].initialize( fitlerSomeValues ).then( magic );

(运算符就像我们一样的空格)

你能想象没有运算符周围的空格吗?

var hello='someting';

if(type===undefined){};

var string="I"+"can\'t"+"read"+"this";

我的工作内容是...

我会在 (){}[] 之间加上空格,例如下面这些例子:

function hello( one, two, three ){

return one;

}

hello( one );

hello({ key: value, thing1: thing2 });

var array = [ 1, 2, 3, 4 ];

array.slice( 0, 1 );

chain[ 'things' ].together( andKeepThemReadable, withPunctuation, andWhitespace ).but( notTooMuch );

9
我认为你错了,不能否定“一直以来我们的做法”的价值。它可能不是唯一的论点,但确实有一些重要性。人们习惯的惯例是易读性的一个因素。我们并不关心所有人(至少英语使用者)的可读性。我们关心程序员的可读性。如果程序员通常已经学会在某些地方加空格来读写代码,那么通过做出一些意外的改变,实际上可能使代码对许多程序员来说更不易读。 - Compeek
当然,团队偏好总是可以被检查的。没有什么是不变的。 - SoEzPz
1
这应该是被接受的答案。我自己来自于 Ruby 的背景,它真的强调你编写的代码应该易读,甚至在大多数情况下都会推荐省略括号(例如不在方法声明中)。无论你对 Ruby 有何看法,但我认为它很愉快地编写和阅读。 - bork
1
我不同意英语语法部分。你选择了唯一一个我们不添加空格的情况,即函数调用,因为我们不想像你描述的那样将调用分开。对于其他运算符,它确实反映出来:“if(condition)”,“while(true)”等。在括号的开头和结尾添加随机空格看起来不太对,感觉好像你正在将其与之分离。 - Simon
我同意这应该是被接受的答案。我真的很喜欢额外的空格,使代码更容易阅读。 - Chris V
显示剩余2条评论

14

在技术层面上,鲜有任何理由支持其中一种 - 几乎全部原因是主观的。

对我来说,我会使用第二种格式,简单地因为:

  1. 它可读性良好,并遵循了Javascript祖先语言中绝大部分的格式约定。

  2. JS文件的下载大小很重要[虽然可以通过代码压缩解决此问题]。

  3. 我总是这样做的。


3
我更喜欢不要多加空格。 - kommradHomer
1
你的第三点的有效性是值得怀疑的。你能解释一下吗? - Kelmikra
1
@Kyth'Py1k,这很难,但对我来说,使用带有额外填充的版本只会感觉“不自然”。 - Alnitak

7

引用《JavaScript编程语言的代码约定》中的内容:

除了. (句号)和((左括号)以及[(左方括号)之外,所有二元运算符都应该与其操作数用一个空格分开。

以及:

函数名和其参数列表的((左括号)之间不应该有空格。


7
与标准一样,会议的问题在于它们太多了... - Alnitak
1
@Alnitak 是的,但这是 Douglas Crockford!;-) - Tomasz Nurkiewicz
4
可能涉及到直流电,但这个文件是一堆不同程度教条主义编码实践和他个人主观偏好格式的混合体。两者并不相同。 - Alnitak

2

我更喜欢第二种格式。然而,也有编码风格标准坚持使用第一种格式。考虑到javascript通常作为源代码传输(例如任何客户端代码),与其他语言相比,可以看出它在这方面略微更强一些,但只是稍微而已。

我发现第二种更易读,你发现第一种更易读,既然我们不在同一份代码上工作,我们应该各自按自己的喜好去做。如果你和我合作,那么最好选择一种格式而不是混合使用(比任何一种格式都难以阅读),但是在javascript出现之前(在类似C的其他语言中),这样的问题就存在了很久,每种格式都有其优点。


0

我使用了 JSHint 来检查这段代码片段,但它并没有给出这样的建议:

if( window )
{
   var me = 'me';
}

0

我大部分时间使用第二种(无空格)风格,但是如果有嵌套的括号,特别是嵌套的方括号,我会加上空格,因为我发现它们比嵌套的圆括号(括号)更难读。或者换句话说,我会开始任何给定的表达式而不加空格,但如果我发现它很难读,我会插入一些空格进行比较,并且如果它们有帮助,我会留下它们。

关于JS Hint,我不会担心-这个特定的建议更多是一个观点问题。由于这个问题,你不太可能引入错误。


0
我个人在括号和参数之间不加空格,原因是我使用键盘导航和快捷键。当我在代码中导航时,我希望光标跳到下一个变量名、符号等,但添加空格会让事情变得混乱。
这只是个人偏好,因为最终所有内容都会转换为相同的字节码/二进制代码!

-1

标准很重要,我们应该遵循它们,但不是盲目地。 对我来说,这个问题关乎语法样式应该全部围绕可读性。

this.someMethod(toString(value),max(value1,value2),myStream(fileName));

this.someMethod( toString( value ), max( value1, value2 ), myStream( fileName ) );

对我来说,第二行显然更易读。

最终,问题可能归结为个人偏好,但我会问那些喜欢第一行的人,他们是因为“习惯了它”还是真正相信它更易读。

如果这是你习惯的东西,那么为了长期受益,短时间的不适可能值得尝试。


大多数使用第一行所示样式的人会在逗号后面加上空格,并且可能会将每个参数放在单独的一行上或使用中间变量,因为这是一个很长的函数调用。 - ggorlen

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接