这是我个人的喜好，有原因的。
我将在已接受的答案中讨论以下各项，但顺序相反。

• • 注一**不是挑Alnitak的毛病，这些评论对我们所有人来说都是共同的...
• • 注-两个**代码示例不作为代码块编写，因为语法突出显示只会阻止实际的空格问题。

我一直都是这么做的。
这不仅不是为编程实践辩护的好理由，而且也不是为任何反对更改的想法辩护的好理由。
JS文件下载大小很重要[尽管缩小当然可以解决这个问题]

• • 任何通过网络发送的文件的大小总是很重要的，这就是为什么我们要缩小文件来删除不必要的空格。由于JS文件现在可以被缩小，所以关于生产代码中空格的争论没有意义**。
• • moot**：几乎没有或根本没有实际价值或意义;纯学术性的。moot definition

现在我们转到这个问题的核心问题。以下是我个人的想法，我知道可能会引起争论。我并不宣称这种做法是正确的，只是说它目前对我来说是正确的。如果有足够的证据表明这是一个糟糕的选择，我愿意讨论这个想法的替代方案。
它可读性很好，并且遵循了Javascript祖先语言中的绝大多数格式约定
该声明分为两部分："可读性很强"; "并遵循Javascript祖先语言中的绝大多数格式约定"
第二项可以被忽略，因为同样的想法是***我总是这样做。***
所以我们只关注第一部分的陈述***可读性很强，"***
首先，让我们做一些关于代码的陈述。
1.编程语言不是给计算机读的，而是给人读的。
1.在英语中，我们从左到右，从上到下阅读。
1.遵循英语语法中的既定实践将使更大比例的用英语编写代码的程序员更容易阅读代码。

• • 注：**我仅为英语语言建立案例，但可能普遍适用于许多拉丁语语言。

让我们通过删除副词***perfectly***来简化第一个陈述，因为它假定不可能有任何改进，让我们转而处理剩下的内容：*"它是可读的"*。实际上，我们可以在它上面运行所有的JS并创建一个变量："isReadable"为布尔值。

• • 问题**

这个问题提供了两种选择：

( foo === bar )

(foo === bar)

如果没有任何上下文，我们可以从英语语法的Angular 来判断错误，然后选择第二个选项，它删除了空格，然而，在这两种情况下，"isReadable"都很容易成为true。
让我们更进一步，删除所有空格...

(foo===bar)

我们还能Assert*isReadable*为真吗？这是布尔值可能不适用的地方。让我们把isReadable移到Float，其中0是不可读的，1是完全可读的。
在前面的三个例子中，我们可以假设，对于每个例子，从我们询问的每个人那里，我们都会得到一个范围在0 - 1之间的值集合："在0 - 1的范围内，您如何评价此文本的可读性？"
现在让我们向示例中添加一些JS上下文...
1.第一个月

1. if(foo === bar){};
2. if(foo===bar){};
   我们的问题是："在0 - 1的范围内，您如何评价此文本的可读性？"
   我在这里假设空白是平衡的：空格太少，isReadable接近0;空格太多，isReadable接近0。
   例如："你好吗？"和"你好吗？"
   如果我们在许多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;

由于我们没有完全反映正确的英语语法，但英语语法确实说需要一个break，那么也许在括号之间添加空格可能会让我们更接近isReadable中的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";

我所做的...
I在()、{}和[]之间的空间;如下面的例子

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 );

几乎没有什么技术上的理由让你更喜欢一个而不是另一个--这些理由几乎完全是主观的。
在我的情况下，我会使用第二种格式，原因很简单：
1.它可读性很好，并且遵循了Javascript祖先语言中的绝大多数格式约定

1. JS文件下载大小很重要[尽管缩小当然可以解决这个问题]
   1.我一直都是这么做的。

引用Code Conventions for the JavaScript Programming Language：
除.（句点）、(（左括号）和[（左括号）外，所有二元运算符都应与其操作数用空格分隔。
以及：
函数名与其参数列表的(（左括号）之间不应有空格。

我更喜欢第二种格式。然而，也有一些编码风格标准坚持第一种格式。考虑到javascript经常作为源代码传输（例如任何客户端代码），人们可以看到它比其他语言稍微强一点，但只是稍微强一点。
我觉得第二个更可读，你觉得第一个更可读，因为我们不是在同一个代码上工作，我们应该各自坚持我们喜欢的。如果你和我合作，那么我们选择一个可能会更好，而不是混合他们（可读性比任何一个都差），但是尽管在JavaScript出现之前很久就已经有了关于这些问题的圣战（在其他具有类似语法的语言中，如C），两者都有各自的优点。

大多数时候我使用第二种（无空格）样式，但有时候如果有嵌套的括号，我会加空格--特别是嵌套的方括号，由于某种原因，我觉得它比嵌套的曲括号（圆括号）更难读。或者换句话说，我会以无空格开始任何给定的表达式，但如果我觉得难以读，我会插入一些空格来比较，如果它们有用，就留着它们。
关于JS提示，我并不担心--这个特别的建议更多的是一个观点的问题。你不太可能因为这个而引入bug。

我使用JSHint来lint这个代码片段，它没有给予这样的建议：

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

我个人在括号中的参数和括号本身之间不使用空格，原因只有一个：我使用键盘导航和键盘快捷键。当我在代码中导航时，我希望光标跳到下一个变量名、符号等，但是添加空格会把事情搞砸。
这只是个人喜好，因为在一天结束时，所有的代码都转换为相同的字节码/二进制代码！

标准是重要的，我们应该遵循它们，但不能盲目。对我来说，这个问题是关于语法样式应该是所有关于可读性。

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

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

第二行对我来说显然更易读。
最后，这可能归结为个人喜好，但我想问那些喜欢第一行的人，他们是否真的因为“他们用过它”或因为他们真的相信它更具可读性而做出选择。
如果你已经习惯了，那么为了长期的利益而在一个小的不适上短期投资可能是值得的。