🚫

TS/JSでセミコロンをつけないスタイル(No-Semi)について

に公開
9
Sparkle AIブログ

Discussion

クロパンダクロパンダ

TSでのno-semi、確かになと思って読んでました。事前にシンタックスがチェックされるのでセミコロンつけないことで起きる諸問題も回避できますし、トランスパイルもされるので。

ただ、JSのほうは以前semiのほうが良いんじゃないかなと思いました。静的型検査されないので 諸問題 が起きる可能性があります。
そもそも、TSがない時代のJSにおいてセミコロン派が主流だったのは、自分のJSスクリプトのあとに実行されるJS、前に実行されたJSの影響を受ける可能性がある、というのも理由の一つだったと思います。(const x = someFunc() のあとに (function(){})() が読み込まれるとエラーになるなど)

いまは各バンドラ、ビルドツール側である程度配慮されているはずだから問題は減ったとはいえ、上にあげた問題をすべては回避できないので、JSに関してはつけたほうが楽なんじゃないかなと思いました。

あいや - aiya000あいや - aiya000

蛇足ですが、弊社Nuxt(TypeScript)テンプレートの前身では

const x = someFunc()
(function(){})()

していると、以下に自動整形されていた気がします。

const x = someFunc()
;(function(){})()

eslintでも自動フォーマットさせていたので、いずれかのルールがやってくれていたのかもしれません。

参考までに、現行の弊社Nuxt(TypeScript)テンプレートを上げておきます。
ただしまだ開発中であり、自動フォーマット周りが怪しいので、上記のフォーマットはしてくれないかもしれません。
https://github.com/PublicHIKKY/vket-boilerplate-nuxt

culageculage

例えばここに No-Semi スタイルで書いた分割代入のサンプルコードがある。

let a, b, c
a = "hoge";                     // 通常の代入
[b, c] = ["fuga", "piyo"]       // 分割代入
console.log(a, b, c)            // 結果出力 "hoge", "fuga", "piyo"

おやおや、スタイルに反して「通常の代入」行にセミコロンが混入していますよ……と思ってセミコロンを削除するとこのコードは正しく動作しなくなる。
No-Semi スタイルでも、このセミコロンは必須である。
(セミコロンが無いと「a = "hoge"[b, c] = ["fuga", "piyo"]」だと解釈されるので)

もちろん、こんな問題があるという議論も尽くされた末にNo-Semiスタイルが導入されてきたんだろうけれど、そんな気軽に選択していいスタイルじゃないと思う。

フシハラフシハラ

処理の区切りで絶対書き間違いがあるから想像も出来ないけど、tsで20%も採用しているのは驚き。

rithmetyrithmety

今時のプロジェクトは Git を使ってますね
そしてセミコロンのあるコードは Git との相性が悪いです

no-semi は true であるべきで trailing-comma も同様に all の方が良いですし
ファイルの末尾には改行が入っているべきです

  obj.hoge()
-   .fuga(); // 不要な diff が出てしまう 邪魔で読みづらい
+   .fuga()
+   .piyo();

個人的にはセミコロン無しでの意図しないコードの検出は TypeScript よりも Prettier のようなフォーマッタの貢献が大きいと思います
たとえば下記のようなコードはフォーマッタをかければ明らかに意図しないコードになって気づけるか、あるいは正しく修正されます

let a = []
[b, c] = d

私が知る限りでもセミコロン要らない派の意見はどれも古いプロジェクトでしか役に立たないものばかりに感じますし
セミコロンを入れていたためにおこるバグもありますね…

// 新しく div を追加しました!
return <div>
  <span>hello, world</span>;
</div>;
mikamika

セミコロンは多くのプログラマの時間を無駄にしキーボードの寿命を奪ってきた悪魔だと思っています

mashuelmashuel

我が流派では不要な所(改行削除しても影響皆無)だけ積極的に省略