在程序员这个行业，撕逼会发生在任何地点、任何时间、任何观点，有的时候会让人猝不及防。
曾经看过一个段子，分享一下：
程序员的鄙视链是什么？
老婆漂亮的程序员，鄙视老婆不漂亮的程序员；
有老婆的程序员，鄙视没有老婆的程序员；
没有老婆有女朋友的程序员，鄙视单身程序狗；
在单身狗之间，才有语言、编辑器、操作系统、代码风格等等内容的互相鄙视；
本文的观点仅代表作者自己的看法。轻喷。
前两天无意中看到一篇文章，文章说的啥内容记不清，我翻了很久的chrome history都没找到。既然我对这篇文章讲的内容都记不得了，那为何我会依然记得这篇文章呢？
因为这篇文章让我改变了我长久以来的关于“到底要不要在程序写分号”这一观点。
我是一名前端开发，日常的本职开发中会接触三种语言javascript、css、html三兄弟。而且我是一名偏向Javascript的前端开发，可以说Javascript是我的主力语言。在我5年多的前端开发工作生涯中，我的code style有着较重的开源倾向和google style。
当然这也不是绝对的，比如google style和github的很多流程开源前端项目中，采用的是2个space的indent，但是我一直都是用的4个space的indent，因为我觉 得2个space的缩进看起来好拥挤。再比如，在写匿名函数或者函数表达式时，我一直采用的都是如下的风格，
var v1;
var v2;
var v3;
var foo = function () {
// your code goes here
};
(function (arg) {
// your code goes here
})();
即，在关键字function与()之间留一个space。
上面的代码段，是我之前进行前端开发采用的code style。但是在我现在看来，每一个语句后的;好碍眼。对比一下，
var v1
var v2
var v3
var foo = function () {}
!(function () {})()
个人觉得现在采用这种方式，更加优雅，看起来更加舒服，说的严重点，就是开发体验更好。
为了能让我这种主观体验能够站得住脚，我绞尽脑汁想出来以下几个原因来挽尊，
- 以前为什么要写分号？一部分是因为一些静态强类型语言的语言要求，比如Java、C之类。另一部分原因早期的编译器或者解释器功能和性能跟不上开发需求，需要开发时人为的规避一些陷阱。但是现在，这些都不是问题了，因为现在的编译器功能很强大，性能很强悍。
- 针对Javascript来说，Javascript的解释器在解释代码时，往往会自动的在每行的末尾添加分号。所以开发人员手动在代码文件中书写分号其实是多余的，极端的说，可能还会增加文件的体积。（这点在Javascript中可能会有坑，后面会解释）
- 现在很多的前端开源仓库在自己的源代码中都不写分号，比如vue。
- 很多其他的脚本式语言都是不写分号的，比如python、ruby、go等。Javascript也算是脚本式的语言。
- 难道不觉得不写分号，代码会看起来更加优雅、更加和谐么？
前方有坑。
在上面的代码块中，如果我这么写，
var foo = function (a) {
console.log(typeof a)
return a
}
(function () {
})()
猜测一下结果是什么。
谜底是function。上面代码块的原理是，Javascript解释器认为第二个()中的function () {}是第一个匿名函数参数a的实参。就是会导致return a的其实是一个函数。
这种情况往往不是我们期望的，一般情况这种情况下，我们需要这些做，
var foo = function (a) {
// your code goes here
}
!(function () {
// your code goes here
})()
就是在后面的自执行函数之前加一个!或者~之类的符号，但是这些符号依然会被当做参数传入第一个函数表达式，所以这里一般是推荐使用分号，如下
var foo = function (a) {
// your code goes here
}
;(function () {
// your code goes here
})()
在Javascript中不写分号可能会遇到的坑，我目前只遇到这一个。在实际开发中有意的规避掉这个坑就行了。
如果还有其他的坑，也欢迎跟我分享。
总得来说，关于代码风格这件小事，其实得看怎么去定位它。如果是单枪匹马的大神，那么可以更加倾向按照自己的风格来；如果身在一个团队中，那么更多的考量是团队风格的统一。只有统一与否，没有严格意义上的好坏之分。
谢谢。
本文文字及图片出自 blog.gejiawen.com
你的反应是：