TC39 委员会正式写入 ES6 规格:请不要省略分号!

2018-01-12 09:36:02 +08:00
 hubert3
许多 JS 开发者喜欢省略行尾的分号,让引擎自动添加。

现在,TC39 委员会正式写入 ES6 规格:请不要省略分号!一个主要原因是,即将进入规格的 class field 是以分号结尾,省略会有危险。另外,自动添加分号的机制是靠猜的,但软件运行不应该靠猜。
https://github.com/tc39/ecma262/pull/1062/files
https://weibo.com/1400854834/FDYzQvUlL
16702 次点击
所在节点    JavaScript
98 条回复
mooncakejs
2018-01-12 12:33:47 +08:00
@est 竟然还有人喜欢 python 的缩进。上班尺子带了没。
Phariel
2018-01-12 12:44:14 +08:00
强迫症表示不加分号我浑身难受。。。
ziki
2018-01-12 12:47:32 +08:00
四个空格啥时候写进标准 /滑稽
xiaojie668329
2018-01-12 12:49:17 +08:00
我不喜欢加分号,但是 prettier 会给我加上去。。。
lyhiving
2018-01-12 12:50:35 +08:00
习惯加分号
blless
2018-01-12 12:53:22 +08:00
@mooncakejs 缩进多了拆分函数啊 看见一个几百行的函数我就头痛
Mitt
2018-01-12 13:14:07 +08:00
妈的 还以为不写分号是大趋势 好不容易接受了设定现在又强制写分号了
otakustay
2018-01-12 13:17:12 +08:00
这楼里已经没一个人在认真看问题了,我贴一下关键的内容:

> What we state here is that using ASI style is likely to lead to an inconsistent programming style in the future and in result code that requires higher cognitive load to work with.

确实分号自动插入(可省分号)在当前是工作得 OK 的,但是这导致在新语法进来后,需要手动写分号的地方越来越多,那么你写代码的时候就需要越来越多的思考“这里能不能省分号”,变得不友好

> The crux of the issue is that ASI makes it harder for the language to evolve. This is not an opinion but a fact. The committee has tried hard to support a semicolon-free coding style so far, but there are cases where it ’ s not feasible to do so (@bmeck repeatedly pointed to one), and there will be more in the future.

省分号已经严重影响了新的语法的设计,当前的 Class Property 已经遇到这个问题,后面更多语法总会有各种各样的边界情况

---

这里一个本质的问题其实不在于分号,而在于:ES 不把换行符当作语法的分隔符

这一特性导致一个 ES 片段是可以写在多行里的,比如这么写:

const a = 0
[x].map...

这时候没有明确的分号就会完蛋,那么在更多新语法进来的时候,就会死得更惨

与其这样,还不如推荐大家所有该加分号的地方都加上,保持一种一致的编码形式
dtysky
2018-01-12 13:20:47 +08:00
Error Correction

One of the most hotly contested religious wars in the JS community (besides tabs vs. spaces) is whether to rely heavily/exclusively on ASI or not.

Most, but not all, semicolons are optional, but the two ;s in the for ( .. ) .. loop header are required.

On the pro side of this debate, many developers believe that ASI is a useful mechanism that allows them to write more terse (and more "beautiful") code by omitting all but the strictly required ;s (which are very few). It is often asserted that ASI makes many ;s optional, so a correctly written program without them is no different than a correctly written program with them.

On the con side of the debate, many other developers will assert that there are too many places that can be accidental gotchas, especially for newer, less experienced developers, where unintended ;s being magically inserted change the meaning. Similarly, some developers will argue that if they omit a semicolon, it's a flat-out mistake, and they want their tools (linters, etc.) to catch it before the JS engine corrects the mistake under the covers.

Let me just share my perspective. A strict reading of the spec implies that ASI is an "error correction" routine. What kind of error, you may ask? Specifically, a parser error. In other words, in an attempt to have the parser fail less, ASI lets it be more tolerant.

But tolerant of what? In my view, the only way a parser error occurs is if it's given an incorrect/errored program to parse. So, while ASI is strictly correcting parser errors, the only way it can get such errors is if there were first program authoring errors -- omitting semicolons where the grammar rules require them.

So, to put it more bluntly, when I hear someone claim that they want to omit "optional semicolons," my brain translates that claim to "I want to write the most parser-broken program I can that will still work."

I find that to be a ludicrous position to take and the arguments of saving keystrokes and having more "beautiful code" to be weak at best.

Furthermore, I don't agree that this is the same thing as the spaces vs tabs debate -- that it's purely cosmetic -- but rather I believe it's a fundamental question of writing code that adheres to grammar requirements vs. code that relies on grammar exceptions to just barely skate through.

Another way of looking at it is that relying on ASI is essentially considering newlines to be significant "whitespace." Other languages like Python have true significant whitespace. But is it really appropriate to think of JavaScript as having significant newlines as it stands today?

My take: use semicolons wherever you know they are "required," and limit your assumptions about ASI to a minimum.
seki
2018-01-12 13:21:07 +08:00
分号?不接受,不参与,不承认,不执行,废纸一张
hyyou2010
2018-01-12 13:25:57 +08:00
一直觉得不加很别扭
tanranran
2018-01-12 13:32:19 +08:00
@est 哔了我的眼👁
superchijinpeng
2018-01-12 13:33:01 +08:00
上面不是写了 This section is non-normative ?
ES 6 不是已经定稿了?
用 ESLint 规范代码貌似可以在新一行的开始加分号解决这个问题,所以说每一个语句都加分号没必要吧。
ob
2018-01-12 13:35:35 +08:00
必须分号;
xAx
2018-01-12 13:51:47 +08:00
爽,对 vuejs 那套烦的不得了,烧死不加分号的异教徒
TimRChen
2018-01-12 14:14:25 +08:00
@dong3580 eslint ?
dong3580
2018-01-12 14:16:35 +08:00
@TimRChen
是的,编译也会报,所以这该如何解决呢。。。
TimRChen
2018-01-12 14:20:24 +08:00
@dong3580 https://eslint.org/docs/user-guide/configuring#using-eslintrecommended 按配置把"semi": ["error", "always"],去掉,然后再看看?
banricho
2018-01-12 14:28:46 +08:00
认真看内容的没几个,标题党大行其道
写不写分号是编码习惯,ESLint 配置也可以自己改
怪 ESLint 和 Vue 的不是很懂
rocksolid
2018-01-12 15:00:50 +08:00
@est 这是写 python 出身的么....

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/422243

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX