喧嘩を生まないSQLコーディング規約の作り方

SQL

こんにちは。データサイエンティスト兼、データ基盤エンジニアのshobyです。

皆さんは社内でどのようなSQLコーディング規約を設けていますか？

多くのエンジニアが関わるシステムにコーディング規約が必要なように、多くのデータサイエンティストが関わる分析プロジェクトにもSQLのコーディング規約が必要です。 良いコーディング規約は生産性をもたらしてくれますが、悪いコーディング規約は喧嘩を生みます。

今回はTVISION INSIGHTSで社内SQLコーディング規約を決めるにあたって、プログラミング言語全般のコーディング規約を参考に、どのような規約を定めるのが適切かを考えたため、ご紹介します。

最終的に、TVISION INSIGHTSでは、チームメンバー全員でDataGripのFormatterを使ってスタイルを統一し、命名規則だけ必要最低限のルールだけを決めることになりました。

概要

  • 社内コーディング規約を作る上での前提
  • 喧嘩を生むコーディング規約
  • 喧嘩を生まないコーディング規約の運用方法
  • TVISION INSIGHTSのSQLコーディング規約

社内コーディング規約を作る上での前提

社内コーディング規約を考える上で重要なことは、合意と生産性の2点です。

関係者全員に規約の内容ついて合意が得られており、規約を設けることで生産性が向上するのであればどのような規約を定めても問題ありません。

とはいえ、関係者全員が合意しやすく、生産性の高いコーディング規約を作るには、 業界標準のコーディング規約をベースにし、社内向けにカスタマイズして使用するのが現実的です。

喧嘩を生むコーディング規約

解釈により複数の意味に捉えられるルールがあったり、ルールが多く運用が難しい規約は、チーム内で喧嘩が生まれる原因になることがあります。

解釈が個人によって変わったり、ルールが多すぎる規約をきちんと運用しようとすると、コードレビューで書き方についての指摘が頻発するようになります。

これが続くと指摘する側もされる側も疲弊してしまい、下手をするとチームに不穏な空気が生まれるようになります。

コーディング規約で喧嘩をしないためには、必要最低限の厳格なルールのみを、容易な方法で運用していく必要があります。

喧嘩を生まないコーディング規約の運用方法

LinterやFormatterを用いることで、喧嘩を生まずにコーディング規約を運用することができます。

近年、多くのプログラミング言語では、業界標準のルールに沿ったLinterやFormatterが存在します。*1 チーム全員でこのようなLinterやFormatterを用いることで、必要最低限のルールを容易に運用していくことができます。

LinterやFormatterを使う上で重要なことは、LinterやFormatterで指摘されなかったことは極力問題にしないことです。 LinterやFormatterに指摘されなかった書き方については個人の好みの範疇の問題であり、それを押し付けるのは適切ではありません。

ただし、変数などの命名規則に関してはLinterやFormatterでは対応することができないため、 命名規則についてのみ何らかのルールを設けるのが良いと思います。

TVISION INSIGHTSの社内SQLコーディング規約

上記考察から、TVISION INSIGHTSでは、FormatterとしてDataGripを採用し、命名規則に関してはKickstarter SQL Style Guideを参考にすることにしました。

DataGrip: Cross-Platform IDE for Databases & SQL by JetBrains

Kickstarter SQL Style Guide · GitHub

現状、SQLには業界標準となるコーディング規約がなく*2、それに沿ったLinterやFormatterも存在しません。

そのため、SQL向けのIDEとしては実質的な業界標準であるDataGripをチーム全員で採用することで、統一したスタイルでSQLを書けるようにしました。

また、命名規則に関しては、比較的モダンで必要最低限であるという理由で、Kickstarter SQL Style Guideを参考にすることにしました。 こちらに関しては、参考であり、強制はしないようにしました。

まとめ

コーディング規約は、社内で合意が得られるルールを、生産性を上げるために導入するものですが、 導入の仕方が不適切な場合、喧嘩を生む原因になります。

コーディング規約で喧嘩を生まないためには、業界標準の必要最低限なルールをLinterやFormatterを用いて運用するのが適切です。 LinterやFormatterでカバーできない命名規則に関しては、追加でルールを設ける必要があります。

SQLにおいては業界標準の規約が存在しないため、実質的な業界標準のIDEであるDataGripをチーム全員で用いることで、統一したスタイルでSQLが書けるようになります。また、DataGripではカバーできない命名規則に関しては、モダンなKickstarter SQL Style Guideを参考にするのをおすすめします。

*1:RuboCopやSwiftLintなど

*2:SQL Style Guideという規約が提案されてはいますが、業界標準と言われるほど浸透しておらず、長い命名を避ける傾向など、全体として内容が古いように感じられます。SQL向けのIDEであるDataGripが登場し、SQLのコード補完が効くようになった現状、多少長くても適切な名前を付けるのが適切だと思います。