最近、注目を集めている@ferossのJavaScriptスタイルガイド、JavaScript Standard Styleを紹介します。チーム内での開発が円滑になり、プログラミングがより楽しくなります。
JavaScriptスタイルガイドのコーディング規約は、タブとスペースのどちらが良いかといった不毛な議論を無くし、コードに一貫性を持たせてくれます。JSLintやJSHint、ESLintといったLinterで使用できる多くのスタイルガイドのうちの1つです。
もしLinterが分からなければ、SitePointの記事『A Comparison of JavaScript Linting Tools』を参考にしてください。
なぜスタイルガイドが重要なのか
もしコーディング経験が長い人なら、スタイルガイドの重要性は言うまでもないでしょう。何百、何千と同じパターンのコードを書くうちに、美しいコードの書き方が身に付いてきます。突然、誰かがおかしな所に括弧を入れたり、文の末尾にスペースを入れてきたとします。そんなときは声を上げてしまうかもしれません。でもよく考えてください。括弧の位置やスペースの有無は個人的な好みであって、プログラムの挙動にはなにも影響がないのです。
各プログラミング言語では標準となっているスタイルガイドが存在します。Pythonの場合だと正しい書き方を記載した公式のスタイルガイドが公開されています。
標準のスタイルガイドに従ってコーディングすることによって、その言語のエコシステムに対応したプログラムになります。また、最初からほかの人と書き方が近くなるので、オープンソースのプロジェクトにコミットしやすくなったり、ほかの人が自分のプロジェクトにコミットしやすくなったりします。
JavaScriptには公式のスタイルガイドがなく、ダグラス・クロックフォードのThe Good Partsがデファクトスタンダードとなりました。彼の本では、信頼性の高いJavaScriptの書き方と避けるべき機能が書かれています。彼はそれらの手法をJSLintで紹介し、ほかのLinterも同様の基準を採用するようになりました。多くのLinterでは、まだ使用するスタイルガイドの設定が可能で、設定をほかの人にも強制できます。一方、JavaScript Standard Styleは設定が不要です。スタイルガイドを好きかどうかは重要ではありません。チーム内のメンバー全員がスタイルガイドを理解できて上手く機能することが重要なのです。
JavaScript Standard Styleを採用するということは、個人的なコーディングスタイルよりもコードの明確さやチーム内の協調性を重視するということです。これはすべてのプロジェクトや開発文化に当てはまるわけではありません。しかし、オープンソースのコミュニティは初心者にとって敷居が高くなりがちです。基準を明確にして、チーム内で共通認識を持つことによって、プロジェクトがより健全なものになります。
もし現在書いているプログラムに自分以外がコミットすることがなければ、自分が一番楽しくなるようなツールやスタイルガイドを使えば良いでしょう。チームで働く場合は、できる限り衝突を減らし、プロフェッショナルとして小さいことに時間をかけないように努めるべきです。
独自のスタイルでコーディングする前に、既存のスタイルガイドについて学ぶことをお勧めします。
JavaScript Standard Styleについて
- インデント2つのスペース –
- ストリングはシングルクォーテーションで囲む – エスケープを避けるため
- 使わない変数は消す – バグの温床となる
- セミコロンは書かない
- (、[、`を行頭に入れない
- if(condition){...}内の単語の後ろにはスペースを入れる
- function name (arg){...}でfunctionの名前の後ろにはスペースを入れる
- 常に==ではなく===を使う – ただしobj ==nullはnull||undefinedをチェックするために使っても良い
- 常にNode.jsのerr関数のパラメータをハンドリングする
- ブラウザーグローバルの前には常にwindowを付ける – 例外としてdocumentやnavigatorはOK
- open、length、event、nameのような名前を誤って使うことを避けるため
詳細はルールの全リストを参照してください。
一番意見が分かれるのは、言うまでもなくセミコロンの記述が不要かどうかという点です。長年、バグを避けるためにセミコロンを記述することがベスト・プラクティスとされてきました。ダグラス・クロックフォードはこのことを強く主張していましたが、その主張の根底には、C言語の場合セミコロンが必須であり、記述がないと動かないという事実があります。
この点においてJavaScript Standard Styleは私の考えを変えてくれました、JavaScriptはセミコロンがなくても問題ないということです。
JavaScriptの機能であるセミコロンの自動挿入は、ノイズを減らしプログラムを簡潔に保ってくれます。私はセミコロンがないことによるエラーに遭遇したことはありませんし、みなさんもそうだと思います。この点について詳しくは動画の『Are Semicolons Necessary in JavaScript?』を参考にしてください。
すべての人がセミコロンを書かないことに賛同しているわけではありません、有名なスタイルガイドのsemistandard や happinessはセミコロンを推奨しています。これらのガイドが規約における重要な点を見失っていることは残念ですね。
もしある人が1つのルールに対して反対しているとします。あなたは簡単にその考えを変えられますか？
答えはノーです。そう簡単ではありません。規約において大切なことは、非常に細かい点についてこだわり過ぎないことです。たとえば、タブを使うかスペースを使うか、といったような多くの議論は尽きることがありません。これらの議論は日々の仕事の気を紛らわす程度のものです。1日の仕事の終わりに適当な議題と意見を出し合い、それがあたかも規約において重要だと言っているように見えます。彼らが、自分たちの意見を擁護することよりも、価値のあることを見出してくれることを願っています。
個人的にはずっとセミコロンなしのコーディングをやってきました、おそらくRuby、Python、CoffeeScriptといったシンタックスを必要としない言語を使用してきたことが影響しているかもしれません。いずれにしろ私は、シンプルなほどプログラムが明快になると考えています。
良いプログラムの4つの条件
プログラマーとして重要視するべき点を列挙します。
- 正確さ
- 読みやすさ
- 幸せ
- 効率性
JavaScript Standard Styleのようなスタイルガイドに準拠することは、上のそれぞれにおいてメリットがあります。
正確さ
どんなプログラムでも意図した通りに動作し、バグがない状態にするべきです。
スタイルガイド自体がプログラムを正確にしてくれるわけではありませんが、Linterによってリリース前にエラーを検知できます。
読みやすさ
プロの開発者としてプログラムを提供する場合、読みやすさはもっとも大切なことの1つです。プログラムを読んで理解するのは、書くよりも時間がかかります。そのため自分があとで読み返すことや、ほかの人が引き継ぐことを考慮して読みやすくするべきです。
簡潔で分かりやすい規約に沿ってコーディングすることにより、読みやすく理解しやすいコードになります。
プログラマとしての幸せ
この観点において私が最も好きなことは、機械よりも人間に焦点を当てていることです。ただし、チームで開発をする場合、読みやすさやコードの機能性の方が重要なので、この項目を3番目にしています。
人生楽しみたいですよね？ 仕事が早く終わるだけでなくおもしろいなら、それに越したことはないですよね。それは生きる目的の一部でもあります。あなたの人生は思っているより良いものです。
— まつもとゆきひろ
人生は短いです。いちいち個人的な好みによる違いにイライラしながら、コーディング規約を決めている時間はありません。もしJavaScript Standard Styleが、対立意見やチーム内の衝突を防いでくれるのであれば、それは幸せに違いありません。
効率性
最後になりますが、決して重要度が低いというわけではありません。
もし選ばなければならないなら、素早くコードを書くことよりも、正確で読みやすいコードを書くことを選択すべきです。
コンピューターは高速に処理できます。プログラムが効率的ならば、素晴らしいことです。もしパフォーマンスに問題点があれば、ボトルネックを洗い出して、コードをより効率的にする必要があります。
人間はコンピューターのように高速ではありません。そのため効率的に進めることはとても重要です。JavaScript Standard Styleに準拠することで、理解しやすく、コミットしやすいコードになります。さらに一番嬉しいことは、コーディングの対立意見に費やす時間をぐっと減らせることです。
JavaScript Standard Styleを実際に使ってみる
JavaScript Standard Styleを適用するために必要なツールはありません。単にルールを読んで、間違っている箇所をメモしていけば良いだけです。必要ならじっくり時間をかけて読んでみるのも良いです。そうでなければ、とりあえず使ってみましょう。
JavaScriptのコードをLintしてくれるnpmパッケージが存在します。
npm install standard --global
standardを実行すると、該当ディレクトリ内のすべてのJavaScriptファイルに対してLinterを走らせてくれます。
さらにスタイルガイドではお馴染みのテキストエディター向けプラグインも用意されています、以下はAtomにLinterをインストールする手順です。
apm install linter
apm install linter-js-standard
個人的に自動のLintingツールを使うと、コーディングの気が散ってしまいます。もし同じ様に感じるなら、コーディングが終わった後にLinterをかけることをおすすめします。standardコマンドは自動でスタイルガイドに対するエラーを修正してくれるオプションfixもあり、時間短縮に役立ちます。
standard --fix
JavaScript Standard Styleを使うべきか
JavaScript Standard Styleを使うべきか？ 答えは、あなた次第です。
もしスタイルガイドなしでうまくいっているのであれば、意見の対立を覚悟してください。
もし、すでに理想的なコーディング規約を自分で完成していて、それをベースにすべてに適応させたいなら、きっとESLintが役に立つでしょう。
※本記事はTim Severienが査読を担当しています。最高のコンテンツに仕上げるために尽力してくれたSitePointの査読担当者のみなさんに感謝します。
（原文：Why I Use a JavaScript Style Guide and Why You Should Too）
［翻訳：萩原伸悟／編集：Livit］
※2016年11月12日、本文中の翻訳を一部更新しました。
