コーディング規約

はじめに

コーディング規則はコードベースの品質保持と一貫性を保つ上で欠かせない要素です。世の中では多くの企業が自身のコーディング規約を定め運用しています。 しかしこれらの規約を文章として明文化するだけでは強制力がなく時間と共に形骸化してしまいます。 そこで私たちはコーディング規約を Linter の設定ファイルとして管理する方法を採用しています。

Wantedly のコーディング規約の考え方

Wantedly ではコーディング規約を以下のように考えています。

  • みんなが読みやすいコードにするためのツール。

  • 人間が頑張らない。Formatter に任せる。

  • 暗黙の了解にしない。Linter でコード化する。

Wantedly においてコーディング規約は絶対に守らなければいけない規則ではなく、あくまでみんなが読みやすいコードを目指すための道具です。その点コーディング規約を各リポジトリに導入するかどうかは自主性に委ねられています。 また定めたコーディング規約を人間が完璧に守ることはしません。現実的には new joiner が全てのルールを把握することは不可能に近く、慣れた人であってもうっかり規約から外れてしまうことはよくあります。現代においてこのように課題に対しては Linter と Formatter が有効なのでこれらのツールを使います。

各言語の Linter 設定

プロジェクトで使用する各言語の Linter 設定ファイルは以下の場所にあります。 これらの設定は言語によって一部カスタマイズされています。

各言語の Formatter 設定

チームが生産性高くコーディング規約に従うためには Linter に加え Formatter を設定することも推奨されます。 Wantedly で利用している Formatter は以下の通りです。

  • Backend

    • Ruby: 未使用

    • Golang: gofmt

  • Frontend:

    • TypeScript: frolint (internal)

    • Swift: SwiftFormat の .swiftformat ファイル (リポジトリごとに配置)

    • Kotlin: JetBrains IDE標準のフォーマッター

  • その他

    • Protocol Buffers: 未使用

未使用になっている言語については必ずしも利用してはいけない理由があるわけではなく、この先必要があれば導入検討が行われるべきだということに注意してください。

コーディング規約を育てよう

コーディング規約もとい Linter 設定は一度作れば完成というものではありません。真の目的であるコードベースの品質担保と一貫性の保持を実現するためには、技術の進化に伴い、継続的に更新されていく必要があります。普段の開発でもし「あれ？」と思う点があれば、遠慮なく PR (プルリクエスト) を送ってください。規約の変更は PR 上での議論を通じて決定されます。このプロセスによりチーム全体で規約を評価し、改善することが期待されます。

前へコードレビュー次へリリース・デプロイ戦略

最終更新