js return加分号_JavaScript 语句后应该加分号么？

【贺师俊的回答(164票)】:

【2014年1月更新】

当初鉴于本答案过长而可能导致部分“分号党”无法catch到我的主要论点，原本打算重新修订本答案。但是因时间精力因素未予重写，且从本答案的支持来看，为分号正本清源的目的已经达到，所以不再修订本答案。这里仅总结下“分号党”推崇的“总是写分号”风格的最主要缺陷：

1. 人总是有可能忘记写分号。ASI导致无法区分是无意中忘记还是有意不写(代码折行)。

2. “总是写分号”并不能完全解决ASI缺陷(如return后换行会自动插入分号)。

3. “}”后是否要加分号需要回溯到对应“{”之前进行语义判断(是否是函数表达式)，成本远高于前置分号判断(只要对行首字符进行token判断：是否是 [ ( + - / 五个符号之一)。

【以下为原答案】

受邀回答。

首先，加还是不加，这是一个书写风格问题。而书写风格通常有一些外在的考量，比如团队所建立的规则或习惯。@玉伯 的答案就是基于此。我对此基本赞同，不过这其实有点避重就轻，呵呵。另外，即使团队有这样的规则，也未必要通过强制在写代码的时候就要这样写，而可以通过工具达成。比如在源码管理工具上挂上钩子，对提交的源代码自动整理格式。

其次，很多人提到代码压缩问题。我觉得这是非常扯淡的理由。如果2012年的今天一个JS压缩器还不能正确处理分号，这只能说明这个JS压缩器没有达到基本的质量要求，根本不值得信任。

@冯超 和 @CSS魔法 提到的jslint也是一个工具的反面例子。工具是帮助人的，而不应该是强迫人的。不明白这一点，你就不会理解为什么在已经有jslint很多年的情况下，还会出现jshint。

jshint对于不写分号会报warn，但可以通过asi选项关闭(在文件头加上/* jshint asi:true */即可)。

在asi选项说明里，jshint的文档是这样写的：There is a lot of FUD (fear, uncertainty and doubt) spread about semicolon spreaded by quite a few people in the community. The common myths are that semicolons are required all the time (they are not) and that they are unreliable. JavaScript has rules about semicolons which are followed by all browsers so it is up to you to decide whether you should or should not use semicolons in your code.翻译如下(【】里是我添加的说明)：

关于分号有大量的FUD，且是由社区里的一小撮人

【你知道是指谁】散布的。一个常见的流言是必须写分号，不写分号不可靠

【流言的意思是不写分号会导致代码行为不确定】。实际上JS有明确的分号规则，并且所有浏览器

【居然】都忠实遵守了规则。所以是否应该在你的代码里使用分号，完全可以由你自己决定

【而不是由一小撮流言散布者或二逼工具强加于你】。

所以对于可不可以不加分号这个问题，社区是有结论的。

然后所谓“应该不应该”，就只是利弊分析，而不是非黑即白。其中也必定有一些如“可维护性”、“可理解性”甚至“代码美感”之类的貌似“贱人贱智”的问题。不过我相信有经验的程序员还是会在大多数问题上找到共识的。

这个世界上有许多语言。大量语言是不用分号作为EOS(End of Statement)的。有些偏执狂认为不用分号的语言都是垃圾，对此我没啥好说的。

有些语言也是可选分号，比如python。python是可以加分号作为语句结束的。当然绝大多数python程序员是不会加分号的(除了在一行里写多个语句)。所以python和js一样是可选分号！并且python的习惯是不写分号(仅在极少数情况下写)！

也有不少人会指摘python的语法太特殊，比如缩进啥的……不能算是c-style的。不过即使是C风格的语言，也有不写分号的，比如groovy。groovy和js一样是可选分号！并且groovy的习惯是不写分号(仅在极少数情况下写)！

所以至少从同样两个是可选分号的语言来看，不写分号在实践上是可行的。毕竟，既然被设计为可选，那么合理的推断是：语言的设计初衷是倾向于鼓励不写分号。

实际上，不少人(包括我)认为，c-style的分号本来就是多余的。为什么这么说？因为明确的EOS只是给编译器的提示而已。如果漏了分号，编译器会报错。既然它都报错了，显然它知道这里应该有EOS。既然它知道，那么干嘛还要我写？

给编译器以hint，这在几十年前是一个平衡编译器和用户成本的设计。某些语言(如Fortran、Basic等)选择用换行来作为EOS，这样每行只能一个语句，并且一个语句折行必须用特殊的接续符号。某些语言(如C)则选择了通过分号来达成，这样每行可以多个语句，并且一个语句也可以分布在多行。平心而论，我更喜欢前一种策略。不过现实是c-style的语法流传更广，至少当前的工业主流语言都是c-style的。

在c-style语言中，如果既要允许自由折行，又要避免额外的EOS(分号)，编译器会较为复杂，光靠看token是不能确定语句是否结束的(即换行处有可能是语句结束，也有可能不是)——尽管在实践中只需要很少的规则，人就能一目了然的看清语句是否结束，但是parser要处理一切的极端情况，例如在换行前插入注释到底怎么算。而C的设计是遵循所谓worse is better的哲学，非常强调实现简单，一个明确的EOS对于编译器来说绝对是简单的。当初如果有人找K&R去要求应该由编译器判断这里该不该是语句结束，我打包票肯定被K&R扁死。有趣的是，lisp那一帮人更极端，如果你抱怨括号实在太密密麻麻的了，一定有人语重心长的告诉你S表达式才是王道。

其实像C++编译器也已经复杂到超乎想象，按理说可选分号真是小事一桩，但它因为要保持对C的完全兼容，所以还是必须写分号。

python和groovy的parser则都是有名的复杂。这并不完全由允许分号可选造成，但是可选的分号其实是整个语法设计哲学的一环。如Groovy的哲学是PHIM——Parse how I mean。

话说python的语法设计真的非常有意思。它也有问题，比如tab和空格混合，计算机之子@程劭非 曾经惊叹，居然有语言能通过改变注释(注释中可定义tabsize)就改变了语义和行为，真是极品。

当然后来者会吸取教训，比如coffeescript和jade之类的，也都是依赖缩进，但是都不允许tab和空格混用。

所以tab/sp这是python的坑。Guido Van Rossum现在就后悔了。从某种程度上说，JavaScript的分号就有点类似python的tab/sp问题。

正如混合tab/sp是出自GVR的良好初衷(让你们想用啥就用啥)，可选分号也是出自BE的良好初衷(随便你写不写)。也如同tab/sp一样，良好的初衷并不代表就没有隐患。之所以python、groovy就没有可选分号的争议，而js就有争议，其实正说明js存在一些问题。

其实Groovy历史上也是有关于可选分号争议的，参见：Groovy在EOS问题上的痛苦权衡 。不幸的的是，与Groovy早期经过社区激烈的讨论才得到稳定语法不同，JS是一门早熟的语言，一些早期的设计失误没有机会被修复。自动分号插入算法就是其中之一。总体上，自动分号插入算法还算正常，但是在一些小地方留下了不易发觉的坑。比如return语句。

return

{

a:1

}

在return后会自动插入分号，导致完全违背期望的结果。

这一古怪行为往往被解释为在JS中应采用一行内跟随大括号的书写风格(即Java的风格，或者说是K&R的C的原初风格，而不是C#风格)，其实追根述源，问题还是出在分号上。

不要插分号的地方被插了分号，这挺坑爹了，但更更坑爹的是想要插的结果没插。这就是括号的问题。如果下一行的开始是 ( 、 [ 上一行的结尾不会被加上 ; 。

如：

a = b

(function(){

...

})()

会被解释为 a = b(function(){...})()

其实如果我们真想表达上述代码，通常会这样写：

a = b(function(){

...

})()

再如：

a = b

[1,2,3].forEach(function(e){

console.log(e)

})

实际效果等价于

a = b[3].forEach(function(e){

console.log(e)

})

坑爹的是，搞不好这代码说不定还能运行！你要事后通过调试发现这些错误是相当滴痛苦啊。

当然这也不能全赖BE。在JS的早期，还没有数组迭代方法 Array.prototype.forEach/map/filter...等，也没有今天常见的(function(){...})()惯用法，所以这个问题其实很不明显。但是到了今天，这些坑爹的问题就都冒出来了。

实际上，+/-也有问题，但是我们几乎不会在实践中遇到。因为你根本不可能会写行首以 + / - 开始的语句，除了 ++i 之类的语句(但是其实我们都会写成 i++ )。

不过这些问题的解决方案其实也很简单。只要在 [ 、 ( 、 + 、 - 之前加分号就可以了：

a = b

;(function(){

...

})()

a = b

;[1,2,3].forEach(function(e){

console.log(e)

})

有些同学觉得这样很丑。没问题，你可以用void替代; 。

也有不少人觉得这是一种“不一致”，需要记住额外的法则。

我承认采取这样一种方法你必须记住一些特例。但是几乎所有的语言都有一些历史原因导致的坑，并且JS也不止这一个坑。更关键的是即使你采用了总是写;的方法，仍然是有关于EOS的坑，因为造成问题的asi特性仍然存在。比如之前提到的return后面会自动插分号。

总是写分号，相比不写分号但是edge case要在行首加分号，看上去要更“简单”，但这只是描述简单，实际做起来未必更简单。

比如你必须要记得，function表达式后面也要写“;” ！

如：

function a() {

...

}

[1,2,3].forEach(...)

这代码是没问题的，但是你改成

var a = function () {

...

}

[1,2,3].forEach(...)

就有问题了！这坑爹！

对于“始终加分号派”来说，结果就会变成函数后面也一定要加分号。(你分得清函数声明和函数表达式吗？坑爹啊，不如都加！)但是为什么函数就加而 if ... {} 或 for (...) {...} 结构里的大括号后面就不加分号呢？这不是也不一致嘛。

而且，同样是一条特殊规则，行首加分号的规则比函数表达式后面加分号的规则其实要简单！

var a = function () {

...

}

[1,2,3].forEach(...)

还是以上面代码为例。

行首是否要加分号，我只要看本行的第一个字符就可以了。因为对于object[prop]这样的意图，其实没有程序员会写出

object

[prop]

这样的代码。如果他要折行，一定是写成

object[

prop

]

所以行首第一个字符如果是括号，毋庸置疑的，这一定是一个新语句的开始。

反过来，你如果要判断 } 后面是否要加 ; ，你得向上回溯，看清楚整段代码是一个结构呢？还是一个函数？如果是函数的话，是函数声明呢？还是函数表达式！

许多时候，你可能向上翻几页还没找到对应的 { ！或者已经忘记了是几层缩进了！

人不是机器，总有可能忘记写分号。上面的分析说明，对于人来说，行首特例加分号的策略其实更简单易行。而总是加分号的策略听上去简单，执行起来却难！(除非你的策略最后变成了所有 } 之后都加分号——我真见过有人这么做的。)

对人是这样，下面再来看看对机器(引入工具)的情形。特别的，因为有不少人表示他遵循总是写分号的方式是因为他严重依赖jslint。所以我就拿jslint开刀。

对于总是加分号的策略，你希望工具能提示你哪里缺少分号。但是实际情况是，你必须尽量避免写出有歧义的跨行语句，因为工具很难判断是有意为之，还是忘记写“;”。

比如：

a = b

(function(){

...

})();

这代码在jslint的提示是：Expected '(' at column 5, not column 1.

请问你是应该真的按照它的提示把括号移动到b后面吗？？

仔细考虑一下，你就知道这个问题不好回答。因为jslint给出的建议其实是基于“这是合法的代码，只是格式不妥”。虽然我们都知道这更可能是忘记写分号。

再来一个更坑爹的例子：

/*jslint white: true */

var a,b,c,d,e,f,g,h,i,j,k,l,m,o,s;

a=b+c*d-e

/f/g-h*i/j

/f/g.exec(s).map(f);

这段代码在jslint里是不报错的！！！

但是我们是可以看出来这代码很有可能是缺少分号。

这里可以看出，如果排除了whitespace的格式提示(这事儿还是挺常见的，毕竟许多人不喜欢被强制加那么多空格规则)，jslint其实无法在我们最需要帮助的时候帮到我们！因为它无法判断这个地方到底是有意为之(不用;而跨行)，还是忘记写; 。

反过来说，如果采取行首特例加;的习惯，其实工具是很容易判断你是否忘记加了分号。如果加上一些对缩进信息的判断来排除极少数不良的折行习惯(出warn即可)，工具甚至能自动把所有这类分号都加上。

两种策略：

1. 我总是写分号，让工具告诉我哪里我忘记写了(但是有时候可能还报不出来，或报了个其他信息)

2. 我总是不写分号，让工具自动把(由于语言设计缺陷所要求的)必须的分号加上去

哪种更好？

总结：

我所推荐的不写分号的方式，其实不仅是不写分号，而是同时采用更严格的跨行策略，即只允许在当前行处于未完成状态时跨行(就像你在jsshell中输入代码一样)。这条规则其实并不需要特别强制，因为绝大多数程序员一直就是这样在执行。诚然，存在少数人习惯写这样有歧义的折行代码：

a = b + c

+ d + e

+ f + g

但是这个习惯是很容易纠正。并且工具根据缩进等信息是完全能检测到的。

说到这里，也许有些同志认为这只能说明jslint太挫，不能证明到处写 ; 的风格不好。因为工具也可以同时加上其他限制嘛。不过你仔细想想，可以发现这是一个悖论。如果jslint够智能，引入了其他与分号无关的代码风格要求，比如空格和缩进，还有折行风格，确实也可以更精确的找到所有漏掉分号的地方。但是那无非再次证明了一点：编译器(代码分析器)完全可以知道哪里应该有EOS。既然所有的分号其实可以由机器自行加上，那么我们自己还要手写所有分号的意义到底在哪里？！

以上。

【玉伯的回答(16票)】:

看项目，如果是不加的项目，则不加，比如 zepto

如果是加的项目，则加上，比如 jquery

4 空格和 2 空格也是一样，两种风格我都习惯

【田乐的回答(13票)】:

正巧参加了2012的Backbone.js conference，现场很多大神也都讨论了这个非常火热的话题。最后大家公认的结论是这样的：

加与不加是风格问题，风格争议不需要有个定论。关键的问题在于如何“争论”，处理好冲突，学会组织语言减少争议是最重要的。因为分号问题在社区内部造成了很多况日持久的口水战，这些口水战是社区的损失……因为大家在这个时候可以写更多的代码带来更多的功能。

类似的问题还有AMD的module，有的库选择兼容AMD，有的人不愿意。公认结论是应该尊重作者的选择，不要因为这些风格问题而fork。module loader应该设法绕过这些问题，提供兼容的解决方案。How not to argue about semicolons?Andrew Dupont的Slides在这里，欢迎阅读：http://www.slideshare.net/savetheclocktower/how-to-argue-about-javascript-13167253

【长天之云的回答(7票)】:

行尾不写分号已有半年，我学习到的和推荐的是：知道什么时候该加分号比任何时候都加分号要好。

1)掌握一次，就能永久地避免分号陷阱——已经不能比 @贺师俊 的解释更详细了。

2)开发者肯定会要去适应不同项目的代码风格。

尽量不加分号。

我常常发现一万个分号中连一个必要的都没有，去掉了分号不仅看起来不容易累，打起来也不容易累。当然很多人不愿意去理解和接受，据我目测，都被养成了分号强迫症患者。

【winter的回答(8票)】:

自答一下,先说JavaScript自动加分号规则,有3条

当有换行符(包括含有换行符的多行注释)，并且下一个token没法跟前面的语法匹配时，会自动补分号。

当有}时，如果缺少分号，会补分号

当程序源代码结束时，如果缺少分号，会补分号。还有一个特殊规则，就是有些语句中间不准出现换行符，包括：后自增，后自减

return

continue

break这些语句中间出现换行符或者包含换行符的多行注释，会视同出现了分号。

-----------------------------------------------------------------------

先说我是分号党，因为按照前面的规则1，只有JS引擎发现新的token不能跟上一行接上的时候，才会自动补分号。

尽管观察JS语法，大多数行的开头都不能接续到上一行行尾，但是特例总是有的，所以会出现著名的括号问题：

(function a(){})()

(function b(){})()

最糟糕的一点是，我们很难总结出什么样的用法对于不加分号是危险的，这样导致遇到问题很难调试定位。

【教主的回答(7票)】:

其实我和你的论据一样，但我得出的结论却和你不同。你在文章中也提到了修改如果分号没写可能会导致修改一部分代码的时候导致另一部分代码出错。然后有了前置分号的做法。我想说的是，你的做法在解决问题的同时引入了另一个规范，而且这个规范不是一个代码规范而是一个代码风格规范。这样为解决一个问题而引入另一个问题的做法是不太可取的。分号这个问题的本质是：“省略分号会导致代码出现二异性“。你的例子已经很好的说明了这个问题。这个二异性不是机器解释的问题，是人的问题，而你靠一些看似普遍的风格规范来规避这个问题，我感觉是不太靠谱的。以你的例子来说：

var a = b

(function(){})()

这个代码你是如何知道编写者不希望是var a = b(function(){})()的呢？你又以什么理由帮他补分号的呢？所以，编写者出现二异性就必须要由编写者来解决，不应该由另外的人或者程序来猜测。总结起来就是：分号作为js的语句结束符号，不是完全没有用的，他是能够明确的标明语句结束位置，避免二异性的，所以，为了不让解释器或程序的维护者猜测代码的执行状况，请在js代码中需要添加分号的地方填写分号。

【CSS魔法的回答(3票)】:

--------------------------------------------

DC 在他的“精华与糟粕”的理论之上，推崇一套较严格的 JavaScript 代码风格[1]，并在 JSLint 中充分体现。其中一条就是“句末写分号”，这貌似遭到了“无分号党”的强力反驳。

Zepto 的作者最近也加入了“无分号党”，我也因此读过 @yulanggong 贴出的链接[2]，该文作者指名道姓反对 DC，并告诫大众不要迷信权威。分号写与不写的优劣，@贺师俊(hax) 老师的文章[3]也说得很清楚了，这里不赘述。

我自己对分号问题的选择是——写分号。一方面，作为初学者，我更倾向于“小白式严谨”，把自己约束在一门技术的安全范围内。不得不承认，DC 的理论在我这个层次的开发者中很有市场。二来，个人审美无法接受在句首写分号，我估计我也记不住哪些句首需要写分号。第三，很重要的一点，我需要 JSLint。

我现在是 JSLint 的重度依赖者，在提交代码之前都会过一下。我是初学者，在学会建立起完备的单元测试之前，我只能从 JSLint 这里找信心了。在现阶段，我应该算是 DC 粉。

【小虎的回答(17票)】:

在我看来，javascript是最多有奇技淫巧的语言了，为什么呢？因为是错误的设计，然而，大家在错误的设计上，反而讨论的好像很有感觉，说点难听的，走火入魔了，被错误语言设计带进黑洞了，越带越深。

我的建议是在错误的设计上，用我们的常识，用C的语法，该加的，就必须加，不改加的就不加，不要再搞这么多"非主流"了。

加分号是为了告诉编译器语句结束了，别指望编译器去读懂代码的上下文。推测chrome迟早会把JS做成编译语言。

最后的结论就是用常识，人为的来解决错误的语言设计。抵制任何奇技淫巧，抵制任何旁门左道.

【知乎用户的回答(3票)】:

我还想补充一下自己使用过程中感到的方便。我是支持和推荐使用无分号的风格的。这确实是风格和习惯问题。我的习惯除了不加分号，还有两空格缩进

前置逗号

对象字面量或数组字面量两个分号/中括号占两行(第一个分号跟在括号、逗号或等号后面，不换行)，第一行缩进四空格，之后前置逗号，缩进两格用一个 var 语句来举例就是

这样的方便之处在于，如果你要新添加一个声明变量，只要在最后添加即可，如果使用分号结尾、后置逗号的风格，你需要先把最后的分号改成逗号，新加的一行最后也不要忘掉分号。如果你要删除一行，用我上面说的这种的风格只需要直接删除(除非是第一行)，而后置逗号加分号的风格还要把最后的逗号再改成分号。

例外就是删除第一行时，需要把第一个逗号改成 var。不过声明变量时一般把确定的变量放在前面，第一行尽量少改动。说到这里忘了一点，一般把带默认值的声明写在前面，不带默认值的声明写在最后，一般最后一行写多个。

之前我试过第二行以后的逗号对齐 v 来写，但后来发现后面的逗号还是空两格更容易识别。

这是我推荐的写法，不过我想说，整洁易读保持一致性的风格就是好风格。

【知乎用户的回答(1票)】:

补充一点：引自DC在Youtube上的一次演讲;

如果下一行的第一个token是 ( , [ , / , + , - 这五个字符之一的话， Javascript 将不会自动在上一行句尾加上分号。

PS：另外在一些语句中，分号是必不可少的。如for循环语句中的分号，否则会报语法错误。还有在多层嵌套中有时在其中一个以 } 结束的语句中忘了加分号，有时就会出错了

【庄表伟的回答(0票)】:

不加分号 ＜＜ 加分号 ＜＜ CoffeeScript

所以，何必多纠结于JS呢？

【高原的回答(1票)】:

为啥非得把选择限定成只能二选一，要么全加分号，要么全不加分号..... js本来就是可加可不加的......这么多年的混写不也好好的么.....

就跟function()的{前要不要换行一样，个人编写习惯这种东西，每个人都能给自己的习惯找一大堆理由，没啥好争的...

如果项目的后端用的是python那么js就统一不加分号，如果后端用的是php就统一js规范加分号......

如果是后端是nodejs建议采取混排的方式，可加可不加，懒得移动光标就不加，想帮助阅读就断下句加一个呗.....

统一编码习惯和减少思考是提高开发效率的重要手段....

【冯超的回答(2票)】:

可以用jslint 或jshint来验证，这东西越早纠正越好。

等养成习惯纠正起来费劲。

不加的话压缩的时候各种问题，有时候虽然没出问题但是代码的逻辑已经变了，机器无法100%判断准确每一句代码从哪分开，写分号可以完全避免这个问题。

不是所有语句后面都要加，比如if else后面就不需要加分号。

【JamesYoung的回答(0票)】:

其实分号或者换行只是个形式问题，能不能让程序正确运行才是根本问题，分号可以不加，是否应该也是因人而异，只要对语言有足够的了解，达到人剑合一成为剑人的程度，加不加就是庖丁解牛，以无隙入有间，随心所欲的事情了。

【王宇鹏的回答(0票)】:

使用webstorm IDE后 不再是个问题, 一些按照编辑器的提示 严格书写

【温金鹿的回答(2票)】:

不写分号并非是js的强制语法规则。而且js只是保证了可以帮你加上，但并不是一定帮你准确的加上。所以，如果要不写分号，那么就需要建立在JavaScript能够保证正确的给源代码加上分号，当然这个时候不写分号就成为了JavaScript的标准语法规则了。就如同缩进是语法规则的pyhton，所以如果去python那里主张一下去掉缩进会是什么后果可想而知。

非常讨厌前面最长评论里面所谓分号党和分号强迫精神的说法。不写分号也可能是一种标榜自身独特的个性心理。所以，不写分号是在以前大家都写分号的时候突然引入一种不能完全解决问题的半斤八两的方法。写分号存在的问题在不写分号的时候依旧存在，不写分号又会出现类似写分号时的共性问题。所以，不写分号你自豪个神马啊？

大家都吃水果，突然有一天有人说水果里面李子好吃，大家都吃李子吧。果然是争论一片。虽然说爱吃啥吃啥比较明智一点，但是，争论半天到底最终吃的还是不是水果，也没有人关心是拨皮还是不拨皮了。

作为多种语言工具的使用者，从C开始可能保持了写分号，在js这里遇到了一个程序语言定义上出现的分号可不写的大坑，但也不说明从C开始爱写分号有什么错，只是想简简单单的将通用的语法规则用到其他语言上，所以，能够掌握什么时候写什么时候不写的确很流弊，的确很大神。但是我什么时候都写分号，照样不影响正常生理工作也很重要。

所以不写分号很流弊，但是要想让我站到不写分号党，那么就请让不写分号可以保证能够正确的给我加上分号再说吧。

【vvii的回答(1票)】:

这种问题就好比问“网易新闻的每篇正文最后是否需要加‘(全文完)’”

难道不加你就理解不了全文是不是完了吗？

难道机器就非要通过识别全文完才能知道这篇文章结束了吗？

但是为什么还是要加上呢？

我想第一感觉很重要，阅读到全文完，我就不会去想是不是因为网络原因只传输了一半，或者我没有看到右侧的滚动条已经到了底端。这样一个简单的信息，让用户很明确的得到了一个信号，避免了更多的想法。为何不可呢？

一切皆是权衡，JS语句加入分号，可以让你代码的阅读者(包括你自己)很明确的知道一行语句的结束。特别是对于闭包嵌套多层的代码结构来说，一个小小的分号可以简单明了的定义了一个终止，何乐而不为呢？

【张乐的回答(1票)】:

看个人风格吧，如果从C，C++，java转过来的，许多都喜欢在必要的地方都加分号。

我喜欢在所有有必要的地方都加。首先当然是担心压缩出问题(虽然有人觉得这个扯淡)，其次是自己看着不难受。

还有if...else...不管里面的内容有多少，都喜欢加{}，省的以后自己写着写着出问题吧。

还有三目运算符都加括号,比如var v = (xxx === "1234")?111:222;

....

严谨一点总没有错，况且有些时候分号还是必须的。有时候写有时候不写，挺奇怪的。都写上至少看上去风格一致些。

【lorrylockie的回答(0票)】:

真的还没这么纠结这个问题。

我的做法是。有的加，比如var 变量，有的不加，function if， else

【Welling的回答(0票)】:

真佩服写一大段回复的人，就一个分号，顺手一加，不是什么大事。

经常在PHP和JS中切换，所以我的习惯是一直加分号。