【JavaScript】コーディング規約の文字列リテラルのクオートはどれを採択すべきか

 JavaScriptでは、ダブルクオート(”)とシングルクオート(’)、そしてバッククオート(`)、いずれも文字列リテラルとして利用することができます。

 しかし、その自由度こそが、コーディング規約制定時の大きな足かせとなります。

スポンサーリンク
rectangle

問題提起

 JavaScriptの文字列リテラルは、意見が割れ、また不毛な議論が繰り広げられる可能性の高い要素のひとつです。

 どちらが優れているということもなく、規約上定めていないプロジェクトもあるかと思いますが、やはり統一感を重視する人からすれば、どちらかに統一しようと考えることは至極自然なことです。

Google JavaScript Style Guideを参考にする

 ここで、Google JavaScript Style Guideの、5.6.1 Use single quotesを見てみますと、シングルクオートを使うように定められています。

 しかし、以下のような注釈も書かれています。

文字列に一重引用符が含まれている場合は、引用符をエスケープしないようにテンプレート文字列を使用することを検討してください。

テンプレート文字列とは、ES2015で定められた仕様で、バッククオート(`)で囲まれた文字列です。改行、変数、処理の埋め込みを行うことができ、文字列の生成が非常に便利になりました。
詳しくは、MDNのテンプレート文字列ページをご覧ください。

 つまるところ、柔軟な対応が求められています。エスケープ文字が含まれていると、非常に読みづらくなってしまうため、規約の統一性よりも可読性を求めていると言えます。

これからの文字列リテラル

 テンプレートリテラルを利用するのがこれからの主流となってくることが予測されます。テンプレートリテラルは、通常の文字列よりも少し重い処理になりますが、その速度差は僅か10%強です。

console.time("template");
for(let i = 0; i < 100000; i++){
  let str = `abcdefg ${i}`;
}
console.timeEnd("template");    // -> template: 14.157ms

console.time("string");
for(let i = 0; i < 100000; i++){
  let str = "abcdefg" + i;
}
console.timeEnd("string");      // -> string: 12.685ms

 現代の端末においては、もはや誤差です。

エスケープ

 エスケープについては、少し考える必要があります。エスケープ(バックスラッシュ)は、あるだけで非常に読みづらくなる邪悪なものです。

 しかし、シングルクオートやダブルクオート以上にエスケープが必要なケースは、バッククオートにはそれほどありません。

 たとえば、シングルクオートで書くときは、英文の扱いに苦慮することでしょう。

let whoAreYou = 'I\'m John!';

 反面、ダブルクオートを採用するときは、HTML文字列を作成するときや、JSON文字列をべた書きするときに困ります。

let json = "{\"hello\":\"world\"}";
let html = "<div class=\"active\">";

 とんでもない読みづらさですが、バッククオートを使えば何も心配はいらなくなります。

let whoAreYou = `I'm John!`;
let json = `{"hello":"world"}`;
let html = `<div class="active">`;

 しかし、文字列中でバッククオートを多用することがあるかもしれません。その場合、文字列リテラル(シングルorダブルクオート)を利用することを制限する必要はないでしょう。

let shExample = "$ echo today:`date '+%Y/%m/%d'`";

 いくら規約で決めたからといっても、以下のような例はよくありません。

let shExample = `$ echo today:${"`date '+%Y/%m/%d'`"}`;

 可読性が大きく下がる上に、シェルの変数使用と誤認されます。

結局、どれを採択すべきか

 文字列リテラルをどれにするかは一長一短あり、いずれも間違いではありません。しかし、それを採択するにあたって、他のリテラル文字を強く制限することは避けるべきです。

 上述したように、エスケープ文字の地獄によって可読性が著しく犠牲になるようなことは、コーディング規約の本旨に沿ったものではありません。

 JavaScriptに限っては、「あえて規約化しない」という選択肢もあるかもしれません。

まとめ

 コーディング規約は、可読性の向上が大きな目的のひとつです。コード全体の統一感は、あくまでその目的を達成するための手段でしかありません。

 これらを踏まえて、プロジェクトに最適なコーディング規約を考えたいものですね。