コーディングスタイルの統一
Ryo-9399 opened this issue · comments
現状のソースはタブとスペースが統一されていないようです。
その他にも細かいコーディングスタイルのばらつきがあり、これらは.editorconfigやlintツールの導入と同時に統一したほうがよいと思います。
まず、ごく基本的なスタイルを定めるために.editorconfigを追加することは外せないと思います。
.editorconfigに記述できる基本的なプロパティはすべて定めてしまうのがよいでしょう(省略可能なtab_widthを除く)。
- end_of_line
- lf (gitに合わせるため)
- charset
- utf-8
- trim_trailing_whitespace
- true
- insert_final_newline
- true
として、indent_styleとindent_sizeは議論の余地があります。
既存のソースコードを見る限りでは、jsファイルはタブインデントのほうが多い感じでしょうか。
スペースインデントが使われている部分では、インデント幅は基本的にスペース4個分のようです。
jsonファイルについては、ファイルによってスペース幅の混在が見られますが、ここは基本通りスペース2個のインデントでよいと思います。
Lintツールの導入による細かいコーディングスタイルの指定は、コーディングスタイル自体をどのように定めるかだけでなく、その強制の度合いも決める必要があります。
おそらくeslintを導入することでソースコードが定められたスタイルに合致しているかどうかをチェックできるようにすると思われますが(たとえば、$ npm run lintでチェックができるようになる)、
- コミットを行おうとするタイミングでgit hookを用いて自動的にチェックを行い、ルールに反したソースコードが含まれる場合はコミットが阻止される
- 上記に加えてprettierを併用することで、自動的に整形を行ってルールに沿ったソースコードに改変してからコミットさせる
などといったことも可能です。
Lintおよび自動整形用のnpmスクリプトを追加するだけでも効果はありますが、それだけではコミット前のチェックが強制されないため、依然として定められたコーディングスタイルに反したコードがコミットされる可能性があります。
一方で、チェックを強制した場合にはコミットの度に(既にLintツールによるチェックが通ることを確認した後であっても)Lintツールのチェックが終わるのを待たなければならない煩雑さがあるので、これは一長一短という気がします。
またそもそも、eslintだけを入れるのか、それともprettierも併せて導入するのかということも決める必要があります。
個人的な意見としては、jsファイルのインデントについては幅4のタブインデントでいいような気がします。
Lintツールの強制度合いについてですが、まだ導入して試したりはしていないのでわからないものの、既存コードの量が膨大なためlintの実行にそれなりに時間がかかるのではないかという懸念があります。
チェックが通らないコードがコミットに含まれたとしても、lintツールが導入されてさえいればいつでもそれに気づくことはできるので、後から修正のコミットを加えるだけで問題はなくなります。
なので、hook等による強制は行わず、npmスクリプトでlintの実行だけできるようにしておけばいいと思います。
また、prettierによるオートフォーマットも、コマンドによる手動実行さえできればいいような気がします。
参考までに、prettierを試してみたところ、手元のPCでは一番大きいSources/MainProgram.jsで5秒でした。他は長くても0.2秒程度です。コミット時のlintは更新したファイルに対してのみ行われるので、個人的にはhookでの使用も許容範囲かなと思います。
他は特に異論はないですが、prettierを導入するならeslintが一緒に必要かどうかはちょっと疑問に思います。
こちらの環境でもprettierによる整形は長くても数秒で完了したため、hookでの自動実行を含めて導入しました。
git commitを行うと自動的に整形が行われるため、リポジトリにコミットされる.jsファイルは常にインデントなどが正しく整えられた状態になり、普段の開発時にはコード整形のことを意識する必要がなくなります。
一方でeslintはMainProgram.jsに対して数分かかっても処理が終わらなかったため、今回は導入を見送りました。
将来的にES6に対する移行が進んだ際に、「varのかわりにletかconstが使われているかどうか確認する」といったことはlintツールがなければチェックできない、という問題がありますが、今のところはあまり大きな影響はないと思います。
現在ビルドタスクとコード整形のタスクは独立していますが、コード整形によってプログラムの内容は変化しないため、ビルドの前後にコード整形を行ったとしても/行わなかったとしてもビルド結果は変わりません(おそらく)。
そのため、ビルドタスクの実行前にコード整形タスクを走らせる必要もありません。