在《我的javascript代码风格》中,我给的第一条风格就是“以换行结束一句语句,而非分号”。其实这个表达是错误的,它真实的表达应该是“不使用分号作为句尾”,也就是说它隐含了两层意思:1.句尾无分号;2.要正确处理语句结束的问题。在经过几个月的实践之后,今天就来谈谈彻底放弃使用分号作为句尾的感受。
这里需要强调一下,“句尾”是指语句结束,而不是说这一行代码结束,不是说任何地方都可以省略分号,有两个地方的分号是不能省的,一个是for循环语句括号中的分号,另一个是空语句。下文所有“不使用分号”都是指“不使用分号作为句尾”。
为什么不再使用分号作为句尾
越来越多的代码不再使用分号是有原因的,我个人认为主要有以下几点原因:
审美的需要
从代码本身而言,所有句尾分号其实都没有实际意义,它不代表任何执行逻辑(空语句除外),对于我个人而言,可以把这些分号全部当做空语句来看,再每一个语句结束执行一条空语句,它反而是一种另类的写作风格。使用空语句的极端案例,是用代码作画,但凡需要填充的位置就使用分号,因为分号是空语句,代码不会报错,怪才们利用这个特性把代码活生生画成了画。
但是,对于普通项目而言,不可能允许代码作画。极简主义时代,省略分号让代码更加美观。当然,为了迎合这种什么,当代的代码写作除了放弃分号外,还有另外一些改变,比如喜欢将声明分开,而不是使用逗号放在一起。这谈不上好坏,仅仅是个人偏好而已,如果在乎审美,那么这点姑且可以当做是省去分号的优点。
有利于后期代码添加
有分号的情况下,后期如果有跟随代码,就必须先去掉这个分号,然后在写跟随代码,而如果不添加分号,则新代码可以直接加上去。而且现在更喜欢每一个操作独自一行,一般这种添加,都会在换行之后再操作。在git的管理工具中,这一行新添加的代码不会带来文件修改的效果,从某种意义上讲,这也是审美心理的结果。包括每个操作单独成行,其实也是审美心理的结果。
gulp.src('**/*.js') .pipe(minify()) .pipe(gulp.dest('./dist'))
例如上面这段代码,要在dest之后再添加on相关代码,只需要换行后添加即可。为了实现有利于后期代码添加,除了省略分号,大家还乐于使用换行和逗号,即对象、数组、参数等都一行写一个元素,而且最后一个元素添加逗号,这样下次追加元素的时候不必再手动添加这个逗号。
自动插入分号机制(ASI)
JS引擎能够自动处理未以分号结尾的语句,它根据ASI的规则来确定语句的结束,而不是代码中的分号。因为ASI的存在,导致JS是一门在引擎解释时必须以分号作为语句结尾标志的语言。也就是说,引擎是无法自己识别语句是否结束,而必须依靠ASI。然而ASI给开发者留下了坑,它会导致你写代码时得到非预期的执行结果。主要有一下几个坑:
后缀表达式 左值表达式 [无行终结符] ++ 左值表达式 [无行终结符] --Continue 语句 continue [无行终结符] 标识符? ;Break 语句 break [无行终结符] 标识符? ;Return 语句 return [无行终结符] 表达式? ;Throw 语句 throw [无行终结符] 表达式? ;
上面这几种情况需要额外注意,稍不留神就会被坑。
a = 10a++
上面这个代码会被解释为:
a = 10;a;++;
也就是说a ++
操作必须写在同一行内。当然,单独放置++为一行的情况我们一般不会让它发生,但是下面这个情况稍不留神就会发生:
function a() { return { a: 10 }}
上面这段代码return单独一行会导致语句在它后面直接结束,后面跟随的内容不会作为返回值,因此,如果你想要在return后给返回值,一定要和return在同行。
只要注意上面这些情况,就可以避免ASI机制带来的坑。而这些坑也证明一个事实:即使你严格按照代码风格使用分号,也有可能造成错误。所以,关于加不加分号的争论并没有涉及问题本质,问题本质是要理解ASI机制。
放弃使用分号作为句尾的注意点
不使用分号的缺点是什么呢?我的回答是:完全没有!它不会带来任何语法错误,也不会导致阅读代码的理解障碍。很多人会觉得不使用分号会带来一些弊端,但实际上,写分号也无法避免这些弊端。使不使用分号,只是选择问题,而不存在好坏善恶之分,会出问题的代码,使用分号仍然会出问题,不使用分号的代码,只要习惯了写作风格,也不会有任何问题。
不写分号确实需要有几个注意点,你需要深刻理解语句与语句之间的关系,让你的代码更加严谨。这里推荐一篇文章,里面总结了主要的几个注意点,本文就再梳理一下。
当你不使用分号作为句尾的时候,你的注意点应该放到句首。也就是说,当你打算写一个语句的时候,首先应该稍做思想的暂停,确定你是否应该这样开始这条语句。当你打算用“(”、“[”、“/”、“+”、或“-”开始这几个符号开始这条语句时,就要格外小心,因为它们在js中存在两种不同的意义,用汉语里的“一词多义”来解释正好。
(前括号有两种意义:1.提高优先级,2.函数的参数。当然,在正则表达式中还有分组的意思。如何确定是哪种意义呢?[前中括号也有两种意义:1.字面量数组的前中括号,2.数组索引下标的前中括号。你也无法确定是在使用哪一种。/则有正则regexp的前斜杠和除号两种意义。而不同的意义会导致js选择不同的方式对它们进行处理。
如果(前方是变量(或常量),它总是被认为是function的实参的前括号;如果[的前方是变量(包括匿名函数,或常量),它总被认为是数组的下标的前中括号;如果/的前方也存在变量(或常量),它总被认为是除号。
+和-情况稍有不同,因为单纯看+只有加法的加号和字符串连接符的意思,但是其实这两种意义在用法上是一致的,字符串连接符只是做了数据类型的转换。当出现++的时候情况则会改变,例如
x++y
会被认为是x; ++y;
,而非x++;y
。还有一种情况,叫做单目运算,其实是一种省略的写法如:
10 + +'12'10 + -'12''12'- - 10
++代表的是自加,而+ +则代表第二个加号为正号,即后面是一个正数,同理- -的第二个减号代表后面是一个负数。但这都不会代码我们本文中分号带来的问题,我们要看的,是第一个+,也就是除开++自加运算的单独一个加号的情况。所以,+号和-号的两种意义分别是:加减运算和正负单目运算。
如果+或-前面是一个变量(或常量),它总被认为是加减运算,而非正负号;反过来,如果它前面不是变量(或常量),则表示正负号。
例如:
12-4 + 6
'19' ++'9' - 6// 这是一个非常有趣的例子,你可以自己运行试试看
因此,所有以([/+-开头的语句,都必须谨慎行事。
但是,这种使用往往是因为开发者希望一次性完成复杂运算,利用最多的如下:
['click', 'hover', 'mousedown'].forEach(e => bind(ele, e, factory))
想一次性通过[]来绑定一些事件。但是这种用法非常危险,因为[前面如果是变量(或常量)就极有可能引起错误。当然,使用分号可以解决,在[前面加分号成为;[,但是这种前置分号的写法非常不符合我的审美,所有前置符号的形式都不大受我的欢迎。我推荐的简单的方法如下:
var events = ['click', 'hover', 'mousedown']events.forEach(e => bind(ele, e, factory))
把复杂语句拆分成两个简单语句。虽然代码量增加了,但是感官上更加明了,events变量也可以复用。当然,你可能觉得events只用到一次,不应该多增加一个变量。即使如此,你也不应该将[]作为句首,你可以采用函数立即执行的方式来释放内存:
!function(){ var events = ['click', 'hover', 'mousedown'] events.forEach(e => bind(ele, e, factory))}()
前面使用了!而非采用双括号的形式执行函数,也是为了避免(作为句首带来的问题。
我在自己的风格文档里面的建议是:使用变量作为句首。当然这不是必须的,有的时候为了写出具有个性的代码,必须尝试使用一些非一般的手段,这个时候,只需要注意本文涉及的知识点即可。
2017-04-23 9833 代码风格
今天就遇到一个坑:
js = load_file_from_disk(filename)
然后调用 webView.evaluateJavascript(js)
因为 写 js的人,是没有加分号的,然后 eval 一直不工作
而且 eval 里还不能有 // 类型的注释, 必须用 /* */
也是一种场景,应该把对应的js进行编译后保存
’19’ ++’9′ – 6 ,现在chrome上,这样的js语句已经报错了
Uncaught SyntaxError: Invalid left-hand side expression in postfix operation
++’9’,或者++9,都会报这个错误,
关于运算符优先级https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Operators/Operator_Precedence,
++大于+
改成下面这样的,就没有问题了
var i = ‘9’
’19’ + (++i) – 6