- 浏览: 961264 次
- 性别:
- 来自: 上海
文章分类
最新评论
-
sscsacdsadcsd:
mike8625 写道react还要自己的一些标签 还得编译 ...
对于React体系的一点想法 -
mike8625:
说的都是给大公司听的,国内很多还是小公司,做个小项目, 说实话 ...
关于国内前端和JS技术发展的乱想 -
mike8625:
react还要自己的一些标签 还得编译 编译吧浏览器端说还慢 ...
对于React体系的一点想法 -
u012814086:
下意识想到了Golang
JavaScript语句后应该加分号么? -
xueduanyang:
我是水羊,年轻的时候觉得只要有好斧子就能做成好产品,各种产品都 ...
关于国内前端和JS技术发展的乱想
这是一个老生常谈的问题了。我之前就曾经写过一篇blog记录了我对此问题的实践与思考之旅。最近在知乎上又出现了这方面的争论,而且几乎是一面倒的支持“总是写分号”。这让我深深觉得是时候正本清源,祛除迷信了。于是我在问题http://www.zhihu.com/question/20298345下,花了整整一天时间写了以下的回答。
重新发在blog上,主要是因为此文过长,作为知乎的答案或许应该精简一下,但全文内容乃心血结晶,值得留存,照录如下。
首先,加还是不加,这是一个书写风格问题。而书写风格通常有一些外在的考量,比如团队所建立的规则或习惯。@玉伯 的答案就是基于此。我对此基本赞同,不过这其实有点避重就轻,呵呵。另外,即使团队有这样的规则,也未必要通过强制在写代码的时候就要这样写,而可以通过工具达成。比如在源码管理工具上挂上钩子,对提交的源代码自动整理格式。
其次,很多人提到代码压缩问题。我觉得这是非常扯淡的理由。如果2012年的今天一个JS压缩器还不能正确处理分号,这只能说明这个JS压缩器没有达到基本的质量要求,根本不值得信任。
@冯超 和 @CSS魔法 提到的jslint也是一个工具的反面例子。工具是帮助人的,而不应该是强迫人的。不明白这一点,你就不会理解为什么在已经有jslint很多年的情况下,还会出现jshint。
jshint对于不写分号会报warn,但可以通过asi选项关闭(在文件头加上/* jshint asi:true */即可)。
在asi选项说明里,jshint的文档是这样写的:
翻译如下(【】里是我添加的说明):
所以对于可不可以不加分号这个问题,社区是有结论的。
然后所谓“应该不应该”,就只是利弊分析,而不是非黑即白。其中也必定有一些如“可维护性”、“可理解性”甚至“代码美感”之类的貌似“贱人贱智”的问题。不过我相信有经验的程序员还是会在大多数问题上找到共识的。
这个世界上有许多语言。大量语言是不用分号作为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历史上也是有关于可选分号争议的,参见:http://blog.csdn.net/hax/article/details/139490。不幸的的是,与Groovy早期经过社区激烈的讨论才得到稳定语法不同,JS是一门早熟的语言,一些早期的设计失误没有机会被修复。自动分号插入算法就是其中之一。总体上,自动分号插入算法还算正常,但是在一些小地方留下了不易发觉的坑。比如return语句。
在return后会自动插入分号,导致完全违背期望的结果。
这一古怪行为往往被解释为在JS中应采用一行内跟随大括号的书写风格(即Java的风格,或者说是K&R的C的原初风格,而不是C#风格),其实追根述源,问题还是出在分号上。
不要插分号的地方被插了分号,这挺坑爹了,但更更坑爹的是想要插的结果没插。这就是括号的问题。如果下一行的开始是“(”、“[”上一行的结尾不会被加上“;”。
如:
会被解释为
其实如果我们真想表达上述代码,通常会这样写:
再如:
实际效果等价于
坑爹的是,搞不好这代码说不定还能运行!你要事后通过调试发现这些错误是相当滴痛苦啊。
当然这也不能全赖BE。在JS的早期,还没有数组迭代方法 Array.prototype.forEach/map/filter...等,也没有今天常见的 (function(){...})() 惯用法,所以这个问题其实很不明显。但是到了今天,这些坑爹的问题就都冒出来了。
实际上,“+”、“-”、“/”也有问题,但是我们几乎不会在实践中遇到。因为你几乎不可能会写出行首以“+”、“-”、“/”开始的语句,除了 ++i 之类的语句(但是其实我们都会写成 i++)。
不过这些问题的解决方案其实也很简单。只要在“[”、“(”、“+”、“-”、“/”等之前加分号就可以了:
有些同学觉得这样很丑。没问题,你可以用 void 替代“;”。
也有不少人觉得这是一种“不一致”,需要记住额外的法则。
我承认采取这样一种方法你必须记住一些特例。但是几乎所有的语言都有一些历史原因导致的坑,并且JS也不止这一个坑。更关键的是,即使你采用了总是写“;”的方法,仍然不能避免掉进EOS的坑,因为造成问题的asi特性仍然存在。比如之前提到的return后面会自动插分号的问题。
“总是写分号”,相比“不写分号但是edge case要在行首加分号”,看上去要更“简单”,但这只是描述简单,实际做起来未必更简单。
比如你必须要记得,function表达式后面也要写“;”!
如:
这代码是没问题的,但是你改成
就有问题了!这坑爹!
对于“始终加分号派”来说,结果就会变成函数后面也一定要加分号。(你分得清函数声明和函数表达式吗?坑爹啊,不如都加!)但是为什么函数就加而 if ... {} 或 for (...) {...} 结构里的大括号后面就不加分号呢?这不是也不一致嘛。
而且,同样是一条特殊规则,行首加分号的规则比函数表达式后面加分号的规则其实要简单!
还是以上面代码为例。
行首是否要加分号,我只要看本行的第一个字符就可以了。因为对于object[prop]这样的意图,其实没有程序员会写出
这样的代码。如果他要折行,一定是写成
所以行首第一个字符如果是括号,毋庸置疑的,这一定是一个新语句的开始。
反过来,你如果要判断“}”后面是否要加“;”,你得向上回溯,看清楚整段代码是一个结构呢?还是一个函数?如果是函数的话,是函数声明呢?还是函数表达式!
许多时候,你可能向上翻几页还没找到对应的“{”!或者已经忘记了是几层缩进了!
由此可见,对于人来说,行首特例加分号的策略其实更简单易行。而总是加分号的策略听上去简单,执行起来却难!除非你的策略最后变成了所有“}”之后都加分号——我真见过有人这么做的。
对人是这样,下面再来看看对机器(引入工具)的情形。特别的,因为有不少人表示他遵循总是写分号的方式是因为他严重依赖jslint。所以我就拿jslint开刀。
对于总是加分号的策略,你希望工具能提示你哪里缺少分号。但是实际情况是,你必须尽量避免写出有歧义的跨行语句,因为工具很难判断是有意为之,还是忘记写“;”。
比如:
这代码在jslint的提示是:Expected '(' at column 5, not column 1.
请问你是应该真的按照它的提示把括号移动到b后面吗??
仔细考虑一下,你就知道这个问题不好回答。因为jslint给出的建议其实是基于“这是合法的代码,只是格式不妥”。虽然我们都知道这更可能是忘记写分号。
再来一个更坑爹的例子:
这段代码在jslint里是不报错的!!!
但是我们是可以看出来这代码很有可能是缺少分号。
这里可以看出,如果排除了whitespace的格式提示(这事儿还是挺常见的,毕竟许多人不喜欢被强制加那么多空格规则),jslint其实无法在我们最需要帮助的时候帮到我们!因为它无法判断这个地方到底是有意为之(不用“;”而跨行),还是忘记写“;”。
反过来说,如果采取行首特例加“;”的习惯,其实工具是很容易判断你是否忘记加了分号。如果加上一些对缩进信息的判断来排除极少数不良的折行习惯(出warning即可),工具甚至能自动把所有这类分号都加上。
两种策略:
1. 我总是写分号,让工具告诉我哪里我忘记写了(但是有时候可能还报不出来,或报了个其他信息)
2. 我总是不写分号,让工具自动把(由于语言设计缺陷所要求的)必须的分号加上去
哪种更好?
总结:
我所推荐的不写分号的方式,其实不仅是不写分号,而是同时采用更严格的跨行策略,即只允许在当前行处于未完成状态时跨行(就像你在jsshell中输入代码一样)。这条规则其实并不需要特别强制,因为绝大多数程序员一直就是这样在执行。诚然,存在少数人习惯写这样有歧义的折行代码:
但是这个习惯不难纠正,并且工具根据缩进等信息是完全能检测到的。
说到这里,也许有些同志认为这只能说明jslint太挫,不能证明到处写“;”的风格不好。因为工具也可以同时加上其他限制嘛。不过你仔细想想,可以发现这是一个悖论。如果jslint够智能,引入了其他与分号无关的代码风格要求,比如空格和缩进,还有折行风格,确实也可以更精确的找到所有漏掉分号的地方。但是那无非再次证明了一点:编译器(代码分析器)完全可以知道哪里应该有EOS。既然所有的分号其实可以由机器自行加上(无论是加在行首还是行尾),那么我们自己还要手写所有分号的意义到底在哪里?!
以上。
javascript之父就倾向于不是用分号。
先向hax道歉,原来 @贺师俊 哥再次啊。领教了。
Hax 真名就是贺师俊,想发到哪是人家的自由.
你们这帮家伙:
1.听风就是雨,无视明显的事实(什么都没搞清就下评论)
2.缺乏程序员最基础的品质"对事物本质的好奇心".
3.缺乏对人的起码尊重.
hax不用理会他们
一个好的程序员要有打破沙锅问到底的精神, 另外人家费力分析写出来的, 你不需要可以不看, 但是不能否认别人也不需要
这是一种态度,如果是程序员,连这种态度都没有的话还做什么程序员.
一个好的程序员不应该转载了不注明出处。
一个好的程序员要有打破沙锅问到底的精神, 另外人家费力分析写出来的, 你不需要可以不看, 但是不能否认别人也不需要
这是一种态度,如果是程序员,连这种态度都没有的话还做什么程序员.
一个好的程序员要有打破沙锅问到底的精神, 另外人家费力分析写出来的, 你不需要可以不看, 但是不能否认别人也不需要
重新发在blog上,主要是因为此文过长,作为知乎的答案或许应该精简一下,但全文内容乃心血结晶,值得留存,照录如下。
首先,加还是不加,这是一个书写风格问题。而书写风格通常有一些外在的考量,比如团队所建立的规则或习惯。@玉伯 的答案就是基于此。我对此基本赞同,不过这其实有点避重就轻,呵呵。另外,即使团队有这样的规则,也未必要通过强制在写代码的时候就要这样写,而可以通过工具达成。比如在源码管理工具上挂上钩子,对提交的源代码自动整理格式。
其次,很多人提到代码压缩问题。我觉得这是非常扯淡的理由。如果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历史上也是有关于可选分号争议的,参见:http://blog.csdn.net/hax/article/details/139490。不幸的的是,与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其实无法在我们最需要帮助的时候帮到我们!因为它无法判断这个地方到底是有意为之(不用“;”而跨行),还是忘记写“;”。
反过来说,如果采取行首特例加“;”的习惯,其实工具是很容易判断你是否忘记加了分号。如果加上一些对缩进信息的判断来排除极少数不良的折行习惯(出warning即可),工具甚至能自动把所有这类分号都加上。
两种策略:
1. 我总是写分号,让工具告诉我哪里我忘记写了(但是有时候可能还报不出来,或报了个其他信息)
2. 我总是不写分号,让工具自动把(由于语言设计缺陷所要求的)必须的分号加上去
哪种更好?
总结:
我所推荐的不写分号的方式,其实不仅是不写分号,而是同时采用更严格的跨行策略,即只允许在当前行处于未完成状态时跨行(就像你在jsshell中输入代码一样)。这条规则其实并不需要特别强制,因为绝大多数程序员一直就是这样在执行。诚然,存在少数人习惯写这样有歧义的折行代码:
a = b + c + d + e + f + g
但是这个习惯不难纠正,并且工具根据缩进等信息是完全能检测到的。
说到这里,也许有些同志认为这只能说明jslint太挫,不能证明到处写“;”的风格不好。因为工具也可以同时加上其他限制嘛。不过你仔细想想,可以发现这是一个悖论。如果jslint够智能,引入了其他与分号无关的代码风格要求,比如空格和缩进,还有折行风格,确实也可以更精确的找到所有漏掉分号的地方。但是那无非再次证明了一点:编译器(代码分析器)完全可以知道哪里应该有EOS。既然所有的分号其实可以由机器自行加上(无论是加在行首还是行尾),那么我们自己还要手写所有分号的意义到底在哪里?!
以上。
评论
14 楼
u012814086
2015-05-27
下意识想到了Golang
13 楼
justjavac
2013-08-15
wzwahl36 写道
为什么会产生分号争议?python为什么不存在分号争议?考虑过这个问题没?
机制不一样,造成了结果不一样,好好加分号,会把你累死?会产生争议?不加分号才是造成这个争议的最大原因。
机制不一样,造成了结果不一样,好好加分号,会把你累死?会产生争议?不加分号才是造成这个争议的最大原因。
javascript之父就倾向于不是用分号。
12 楼
wzwahl36
2013-08-15
为什么会产生分号争议?python为什么不存在分号争议?考虑过这个问题没?
机制不一样,造成了结果不一样,好好加分号,会把你累死?会产生争议?不加分号才是造成这个争议的最大原因。
机制不一样,造成了结果不一样,好好加分号,会把你累死?会产生争议?不加分号才是造成这个争议的最大原因。
11 楼
ih0qtq
2012-07-13
不看文章,直接看评论,也是一种态度.
10 楼
justjavac
2012-06-20
hax 写道
本文并非转载。OK?
justjavac 写道
一个好的程序员不应该转载了不注明出处。
先向hax道歉,原来 @贺师俊 哥再次啊。领教了。
9 楼
xiaotot
2012-06-20
必须写,不必须写,有这么绝对么?
8 楼
liu78778
2012-06-20
justjavac 写道
应注明出处。『知乎』
Hax 真名就是贺师俊,想发到哪是人家的自由.
你们这帮家伙:
1.听风就是雨,无视明显的事实(什么都没搞清就下评论)
2.缺乏程序员最基础的品质"对事物本质的好奇心".
3.缺乏对人的起码尊重.
hax不用理会他们
7 楼
hax
2012-06-19
本文并非转载。OK?
justjavac 写道
一个好的程序员不应该转载了不注明出处。
6 楼
justjavac
2012-06-19
ih0qtq 写道
liu78778 写道
a34020249 写道
真的懒得讲你的,一个分号能说这么一大堆,渣。。。。。
看你那变成风格渣。。。。。。。
看你那变成风格渣。。。。。。。
一个好的程序员要有打破沙锅问到底的精神, 另外人家费力分析写出来的, 你不需要可以不看, 但是不能否认别人也不需要
这是一种态度,如果是程序员,连这种态度都没有的话还做什么程序员.
一个好的程序员不应该转载了不注明出处。
5 楼
tlde_ti
2012-06-19
这一古怪行为往往被解释为在JS中应采用一行内跟随大括号的书写风格(即Java的风格,或者说是K&R的C的原初风格,而不是C#风格),其实追根述源,问题还是出在分号上。
-------------------------
这一点有点不赞同,这个的确是semi-colon inference导致没有实现这种风格,但那也是因为支持这种风格以后,inference要处理的情况无谓的变得很复杂,而其达到的效果和
return {
a:1
}
这种风格确是一样的。没有多少好处却可能带来更多的工作和bug.
所以我是觉的不支持这种风格不算问题.
-------------------------
这一点有点不赞同,这个的确是semi-colon inference导致没有实现这种风格,但那也是因为支持这种风格以后,inference要处理的情况无谓的变得很复杂,而其达到的效果和
return {
a:1
}
这种风格确是一样的。没有多少好处却可能带来更多的工作和bug.
所以我是觉的不支持这种风格不算问题.
4 楼
ih0qtq
2012-06-19
liu78778 写道
a34020249 写道
真的懒得讲你的,一个分号能说这么一大堆,渣。。。。。
看你那变成风格渣。。。。。。。
看你那变成风格渣。。。。。。。
一个好的程序员要有打破沙锅问到底的精神, 另外人家费力分析写出来的, 你不需要可以不看, 但是不能否认别人也不需要
这是一种态度,如果是程序员,连这种态度都没有的话还做什么程序员.
3 楼
liu78778
2012-06-19
a34020249 写道
真的懒得讲你的,一个分号能说这么一大堆,渣。。。。。
看你那变成风格渣。。。。。。。
看你那变成风格渣。。。。。。。
一个好的程序员要有打破沙锅问到底的精神, 另外人家费力分析写出来的, 你不需要可以不看, 但是不能否认别人也不需要
2 楼
a34020249
2012-06-19
真的懒得讲你的,一个分号能说这么一大堆,渣。。。。。
看你那变成风格渣。。。。。。。
看你那变成风格渣。。。。。。。
1 楼
justjavac
2012-06-19
应注明出处。『知乎』
发表评论
-
论ES6模块系统的静态解析
2013-03-14 04:56 15875本文是Dave Herman的《Stati ... -
如何创建一个JavaScript裸对象
2012-08-27 02:11 8050所谓裸对象,即 naked object ,是指没有原型(sp ... -
shim是应该抛异常还是应该fail silently?
2011-08-11 17:26 5579玉伯发布了es5-safe模块 ... -
7月30日的广州演讲视频和Slides
2011-08-01 23:38 31757月30日在W3CTech广州站活动上的演讲,题目是:ECMA ... -
如何判断一个函数的意图是被用作构造器,也就是可视为“类”
2011-07-21 13:55 2947前提是不要求做什么特殊标记。只是最大可能的猜测函数的作用大概是 ... -
关于国内前端和JS技术发展的乱想
2011-07-19 18:53 33267玉伯在我的一条微博后面写了一些(和主题不是很相关但)非常值得思 ... -
Module与Trait的比较
2011-08-12 12:50 4004最近我多次提及module和trait。 粗看,我们可以发现 ... -
如何将let结构(block scope)转换到当前的JavaScript代码
2011-07-12 17:24 3005本文是对如何将let结构转换到ES3代码的补充。 首先,原文 ... -
JavaScript的未来方向之观察
2011-07-12 02:53 8371最近每次去杭州,都有 ... -
我为什么力挺NodeJS
2011-07-04 00:27 0之前在参加CNodeJS社区在 ... -
JS之父再谈JS历史(续完)
2010-12-31 04:20 3438又到年底,我觉得是时候还债了。自开blog来,我出了不少“太监 ... -
我为什么是DC黑续,兼答Tin
2010-04-27 14:29 0我同意安全是一个重要问题。我不同意的是把所谓安全放到凌驾于其他 ... -
我为什么是DC黑─Why I disagree with Douglas Crockford
2010-04-26 17:51 11015参加完了QCon北京大会, ... -
写对正则:一行代码,速度差50倍
2009-05-12 03:43 60132009-05-11 A lesson of ... -
JavaScript的EOS(分号)问题
2009-05-08 16:24 5777在http://bbs.51js.com/viewthre ... -
JavaScript五大关键字
2009-05-06 17:53 4767近期做语法高亮项目的副产品,是统计了一下几个主流JS工具包中各 ... -
curry和partial的差别
2009-03-28 00:15 371351js上asfman翻译了http://ejohn.org/ ... -
Eval is Evil , With evil too
2009-03-27 18:39 0with的问题: 2009-3-27 17:12:40 ... -
IE全局变量的Dissociative Identity Disorder(人格分裂症)
2009-03-16 02:47 14736最近,小麦提出了一个疑惑: 小麦 写道最后介绍一个我也搞不明白 ... -
JScript下Array对象的性能问题
2009-02-14 02:51 4003今天看了微软JScript官方blog上去年的两篇文章: ht ...
相关推荐
js语句后应该加分号吗? javascript大括号后面应使用分号吗?JS中function 的开头有加感叹号、分号是什么意思呢? Js多个文件集成成一个文件后,压缩代码时避免发生语法错误,可以如下处理 一、js 前加分号 例如:;...
首先,了解JavaScript语句后面可能出现分号的规则很重要,因为它们是JavaScript解释器用来分隔语句的关键符号。在某些情况下,解释器会自动插入分号来结束一个语句,以避免语法歧义。自动加分号规则有三条: 1. 当...
javascript每条语句都是以分号结束,但由于javascript具有分号自动插入规则,所有不同的编程人员有不同的习惯,有的加分号,有的不加分号,那么到底加分号好还是不加分号好?本文章向大家探讨javascript每条语句该不...
JavaScript语句是构成程序的基本单元,它们向浏览器发出指令,指示浏览器执行特定的操作。例如,`document.getElementById(demo).innerHTML='Hello World';` 这个语句就是用来修改id为'demo'的HTML元素的内部HTML...
分号在JavaScript中作为语句的终止符,它的主要功能是作为语句的断言(End Of Statement, EOS),用来结束一个程序语句。尽管在很多C风格的语言中,分号的存在主要是为了简化编译器的设计,但现代编译器已能够高效地...
例如,如果在`if`语句后的花括号前添加了分号,代码将不再按照预期执行: ```javascript if (i % 2 !== 0); { sum += i; } ``` 在这个错误的版本中,分号使得`if`语句成为一个独立的、不执行任何操作的空语句,...
JavaScript语言有一个机制:在解析时,能够在一句话后面自动插入一个分号,用来修改语句末尾遗漏的分号分隔符。然而,由于这个自动插入的分号与JavaScript语言的另一个机制发生了冲突,即所有空格符都被忽略,因此...
JavaScript 语句 JavaScript 语句向浏览器发出的命令。语句的作用是告诉浏览器该做什么。...分号用于分隔 JavaScript 语句。 通常我们在每条可执行的语句结尾添加分号。 使用分号的另一用处是在一行中编写多条语
在学习JavaScript之前,我们首先应该了解为什么需要学习这门语言。JavaScript之所以受欢迎,主要是因为它能够操控浏览器,具备广泛的使用场景,并且学习起来相对容易。JavaScript的性能强大,它是一种开放的语言,...
了解了这些特定情况,我们可以得出结论,Node.js中的加分号遵循的原则是:在代码块的结束花括号后、以`[`或``开头的行开始处,以及在任何有可能导致JavaScript引擎误解语句边界的地方,都需要手动添加分号。...
)用于表示JavaScript语句的结束,虽然不是强制性的,但推荐在每条语句末尾使用分号。如果省略分号,JavaScript会尝试自动插入,但这可能导致代码出错,尤其是在压缩或自动格式化的代码中。良好的编码习惯是每行语句...
在源代码文本中,这些分号可以被显式地写出来,但出于便利,某些情况下这些分号可以从源代码文本中省略,并且在JavaScript解析引擎解析源码时,会自动将分号插入到代码流中,从而形成完整的语句。 例如,当一个...
Javascript伪协议是一种特殊的协议类型,它可以将javascript代码添加到客户端,javascript伪协议的URL中包含javascript代码,浏览器会将其解释为javascript语句,并执行之。这种协议类型可以用于触发XSS漏洞,危害...
5.8 JavaScript语句小结116 第6章 对象118 6.1 创建对象120 6.2 属性的查询和设置123 6.3 删除属性127 6.4 检测属性128 6.5 枚举属性130 6.6 属性getter和setter132 6.7 属性的特性134
- **语句**:JavaScript中的语句是由一系列命令组成的,通常以分号结束。 - **代码位置**:JavaScript代码可以写在HTML文档的头部(`<head>`部分),也可以写在主体部分(`<body>`部分),还可以通过外部文件引用。 ...
然而,这种灵活性也带来了一些特有的挑战,其中之一就是JavaScript语句可以不以分号(;)结尾。这种特性源于JavaScript的自动分号插入(Automatic Semicolon Insertion, ASI)机制,它允许开发者在某些情况下省略...