Railsのコーディング規約を作る際に参考にしたもの

初めに

Rails/Rubyのコーディング規約やコーディングルールを整備した時に参考にしたもの、使ったものなどをまとめました。

コーディング規約

独自の規約を作るよりは、一般的なコーディング規約を参考にしましょう。

• Ruby
  • Rubyアソシエーション: コーディング規約
• Rails
  • The Rails Style Guide / 日本語訳
• Rspec
  • Better Specs. Testing Guidelines for Developers.

rubocop

細かなコードの書き方をレビューするのは面倒です。そこで使うのが rubocop。
公式通りインストール後、設定ファイルの.rubocop.ymlを編集して利用します。初期設定は厳しすぎるので、少しづつ緩めていきます。以下は設定サンプルです。

.rubocop.yml

AllCops:
  # バージョンアップ時の新ルール適応を実施する
  NewCops: enable

# https://github.com/rubocop-hq/rubocop-jp/issues/32 参照
# 初期値の80は昔の制約に基づくものなので変更、比較的多いMax:120を採用
Layout/LineLength:
  Max: 120

# Classのトップレベルにコメントが無い状態を許可
Style/Documentation:
  Enabled: false

# 日本語によるコメントを許可
Style/AsciiComments:
  Enabled: false

# モジュール内の最大行数
Metrics/ModuleLength:
  Max: 500

# メソッド内の最大行数
Metrics/MethodLength:
  CountComments: false
  Max: 50

# クラス内の最大行数
Metrics/ClassLength:
  CountComments: false
  Max: 500

# ABCメトリックサイズの最大値
Metrics/AbcSize:
  Max: 30

# 循環的複雑度の設定 デフォルトだと小さいので変更 Max20以下が適切か
# 1~10 リクスなし/ 11~20 中リスク / 21~50 高リクス / 51以上 非常に高いリスク
# https://qiita.com/yut_arrows/items/16749e02313109071338
Metrics/CyclomaticComplexity:
  Max: 15

# if/caseなどのガード節を用いた複雑度の設定
# 特に基準値がなかったため、循環的複雑度と同じ設定を適応
# https://docs.rubocop.org/rubocop/cops_metrics.html#metricsperceivedcomplexity
Metrics/PerceivedComplexity:
  Max: 15

# rubocopによるコーディング規約のチェック
$ bundle exec rubocop TARGET_FILE

# 違反箇所の自動修正オプション(安全な修正)
$ bundle exec rubocop -a TARGET_FILE

細かい規約をコーディング規約に載せるよりは、基本は.rubocop.ymlに従うという風にした方が良いですね。

Railsにおけるデザインパターン

• 肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）｜TechRacho by BPS株式会社
• Railsで重要なパターンpart 1: Service Object（翻訳）｜TechRacho by BPS株式会社
• Railsで重要なパターンpart 2: Query Object（翻訳）｜TechRacho by BPS株式会社

Railsのデザインパターンで有名なものですね。良く使うのは

• Service Object
• Form Object
• Query Object
• Decorator

辺りでしょうか。あらかじめ、どのパターンをどのように利用するかなどは、コーディング規約に含めておいた方が良いですね。

一般的な原則、プラクティス

Rails関連のプラクティス

• Railsアプリケーションを遅くするActiveRecordの3つの間違い
• Rails: JOINすべきかどうか、それが問題だ — #includesの振舞いを理解する（翻訳）｜TechRacho by BPS株式会社
• Why inheritance is bad?
• Why don’t Rails developers use Ruby metaprogramming? - Quora

ActiveRecordのパフォーマンスに関連する記事を2つ。パフォーマンス関連だとN+1のチェックでbullet入れるとか、EXPLAINを使ったクエリ実行計画の最適化なども考慮すると良いかもしれません。継承やメタプログラミングは使いどころが非常に難しいです。ある程度規約で制限かけたほうが良いですね。

一般的な原則

• KISSの原則（Keep it simple, stupid.）とは - IT用語辞典 e-Words
• YAGNI原則（You Ain't Gonna Need It）とは - IT用語辞典 e-Words
• DRY原則（Don't Repeat Yourself）とは - IT用語辞典 e-Words
• 開発者が知っておくべきSOLIDの原則|POSTD

一般的な原則。上3つは分かりやすいので、これは必ず見ておいた方が良いですね。

終わりに

コーディング規約といっても、細かな書き方から作成するモジュールの規則など設計に関する物も含まれます。全部チェックするのは大変ですが、便利なツールも出てきています。こういったものを活用していき、品質を高めることは大事です。