コーディング規約：快適に開発できる環境づくりを紹介

こんにちは。rayout TECHチームの山本です！

今日はエンジニアチームのコーディングルールに関してお話させていただければと思います。

弊社はコーディング規約というものを導入して、変数の書き方とか、コードを書く上で悩みがちな部分を予め取り決めておき、コーディングそのものに集中できるようにしようと考えております。

でも、コーディング規約ってなんだか面倒くさそうじゃありませんか…?

大丈夫です！自動化されていますから。

本題に入る前に、少しだけ開発事情についてお話させてください。

💡 記事要約

• コーディング規約を導入しました
• 弊社開発環境で使用している技術（ESLint × PHP CodeSniffer × PHP CS Fixer × Husky）のご紹介

毎日どれくらいコードを書いてるの？

弊社のTECHチームは日々開発に追われており、自社開発サービスや受託の開発などを合わせていくと、１日でだいたい数百行のコード、多いときでは数千行の変更が行われています。

そしてソースコードの変更や追記はGitと言われるシステムで管理されており、管理下のファイルは誰が、いつ、どのファイルに、何をしたのかがわかるようになっています。

ただしこの変更の追跡は良くも悪くも厳密で、半角スペースの数（インデント）単位でもバッチリ記録されます。

変更が増えると大変になってくること

半角スペースの数もバッチリ記録される…こうなってくると、

本当に変更を加えた箇所がわからなくなってきますよね。

基本、開発環境はフォーマッターというものが備わっており、自動でスペースの数などを整えてくれるのですが、これがメンバー間などで異なるとその差分だけ、大きな変更が記録されてしまいます。

下記の画像がフォーマットに実装の変更が埋もれた最たる例です。

左画面が真っ赤になっているところが、フォーマッターが起動しただけの部分です。

ルールを決めなければ。

そこでコーディングをする際のルールを決めておかないと、それぞれのフォーマッターが百科事典のような変更合戦を繰り広げてしまいます。

かといって、ルールを取り決めるのも大変で、インデントだけではなく、改行、変数の初期化の仕方など、取り決めることも多いです。

毎日の開発に追われているなら、なおさらです。議論お蔵入り一直線の予感。

けれどもここに十分なベストプラクティスさえあれば、スムーズな導入が期待できますよね。

そこでコーディング規約を見てみよう

コーディング規約もピンキリですが、どれもこうした問題を取り決めていることが多いです。

結論から言えば、下記の規約を導入しました。

• フロントエンド：Airbnb Coding Style Guide （和訳）
• バックエンド：PSR-12 （和訳）

特にフロントは様々な規約があって悩みましたが、ある程度ネームバリューがあって、モダンな書き方を推奨しているものに絞りました。ネームバリューを重視したのは、新しく入るエンジニアさんのキャッチアップをスムーズにしたい狙いもあります。

そこからメンバー間にサンプルを見せて、Airbnbさんの規約を導入が決まりました。

PHPはもともと規約の種類そのものが少なかったですが、PSR2を2022年に継承したモダンなPSR12を選択しました。

ただ、導入するだけでは充分ではなく、きちんとコードに反映されなければ意味がありませんね。

そもそも、リンクにあるように沢山の規約を覚えること自体が大変です！

なら自動化すればいい！

実のところ、下記の点を処理できればコーディング規約はだいたい自動化できてしまいます。

1. 規約に反している記述に赤線などの警告を入れる
2. インデントなどは保存時に整える

これらは一般的に、ライブラリを導入して、スペースや改行などをどうフォーマットするか、そしてどのような記述を規約に違反しているかを設定ファイルに記述して、実行すればいいことになります。

これのいいところは、設定ファイルそのものが手順書となることです。

例えば、import文はアルファベット順に並べて、未使用の変数は削除して、空白の改行は１行以上はしないほうがよくて、、、といったドキュメントを作成して「今日からこれを守りましょう！」と取り決めても、それを全員が守ってくれるかは未知数です。

設定ファイルそのものが手順書となっていること。プログラムがその実行役を担うこと。

これこそが「エンジニアが煩わしいルールから開放され、如何にコーディングに専念できる環境を提供するか」という問題を解決するためのキモとなると考えています。

手順書すらGitで管理されているため、変更や保守も極めて容易です。

自動化を実現するための技術スタック

技術としては、ESLint × PHP CodeSniffer × PHP CS Fixer × Huskyを使用してファイルの保存時などに処理を走らせます。

以上の取り組みを、下図によって実現しました。

※図はおおまかな表現です

1. ファイル保存時

PHPCSが画面にエラーがあるかどうかを表示して、規約の違反箇所を伝えます。

そして保存したときに、PHP CS Fixer, ESLintがファイルのインデントを設定ファイルの通りに整えます。

1. コミット時

コミットは、かんたんに言えば保存した変更をGitに反映させることです。

コミットをしたときに、Huskyと言われるライブラリが下記の処理を走らせます。

1. フォーマットをしてインデントのズレなどを矯正
2. PHP CodeSniffer, ESLintが規約に違反していないかをチェックし、だめならエラーを投げる

2の手順でエラーがなければ反映されます。

規約、ガッチガチに守りすぎ…？

上記の図だけを見ると、規約を一字一句違わないよう守らなければ通らないんじゃないかと思うかもしれませんが、そんなことはないです。

使用しているライブラリの都合上でやめたほうがいいルール、愚直に守ると記述が冗長になる部分はOFFにするか、エラーだけではなく警告として表示するにとどめています。

導入したときに煩わしくなるのか少し不安もありましたが、すぐにキャッチアップしていただけました。実際、コミットで弾かれたことも3回くらいでメンバーでも好評いただいています！

まとめ

rayoutの開発事情にスポットライトをあててみました。

さらなる展望としては、より品質を挙げられるように、自動テストの充実などを検討しています。

興味持ってもらえれば嬉しいです！