Rubocopの新ルールに対応する設定調整とコード修正

Rubocopの新しいルールへの対応として、プロジェクトのコーディング方針に合わないルールを抑制し、可読性向上につながる箇所ではコードを修正しました。静的解析ツールの要求とプロジェクトの設計判断のバランスを取る変更です。

背景

Rubocopのバージョンアップに伴い、新しいルールが追加されました。これらのルールの中には、RSpecプロジェクトの既存のコーディングスタイルやアーキテクチャの判断と合わないものが含まれていました。すべてのルールに機械的に従うのではなく、プロジェクトの方針に基づいて適切に取捨選択する必要がありました。

#313では、3つのRubocopルールを抑制し、コードの可読性向上を目的とした3箇所の修正を行っています。

技術的な変更

この変更は、主に設定ファイルの調整と、それに伴うコードの微修正から構成されます。

抑制されたRubocopルール

Style/FileOpen はspecファイルで無効化されました。

Style/FileOpen:
  Exclude:
    - '**/spec/**/*.rb'

このルールは File.open の使用を推奨しないものですが、RSpecのテストではファイルハンドルを直接扱う必要があるケースが多く、spec内では無効化されています。

Style/OneClassPerFile はプロジェクト全体で無効化されました。

# require has a cost, albiet a minor one and we've historically
# combined classes into files according to need due to this.
Style/OneClassPerFile:
  Enabled: false

コメントにあるように、RSpecでは require のコストを考慮して、関連するクラスを1つのファイルにまとめる方針を採用してきました。この設計判断を維持するため、ルールを無効化しています。

Style/ReduceToHash も無効化されました。

# We prefer the readability of other styles
Style/ReduceToHash:
  Enabled: false

このルールは each_with_object({}) を to_h に置き換えることを推奨しますが、RSpecチームは既存のスタイルの可読性を優先しています。

コードの修正

文字列リテラルの簡素化が2箇所で行われました。

変更前:

msg = String.new("#{@data.deprecated} is deprecated.")

変更後:

msg = "#{@data.deprecated} is deprecated."

String.new は文字列の変更を意図する場合に使用されますが、この箇所では後続の << 演算子で文字列を構築しているため、通常の文字列リテラルで十分です。

all? メソッドの引数指定形式が3箇所で改善されました。

変更前:

elsif args.any? { |a| a.is_a?(Symbol) }

変更後:

elsif args.any?(Symbol)

any? や all? メソッドに型チェックを渡す場合、引数形式を使うことでブロックよりも簡潔に記述できます。同様の修正が rspec-expectations と rspec-support にも適用されています。

grep メソッドの活用により、Nodeオブジェクトの抽出が簡潔になりました。

変更前:

@children ||= args.select { |arg| arg.is_a?(Node) }.freeze

変更後:

@children ||= args.grep(Node).freeze

grep は型でフィルタリングする場合に select よりも意図が明確になります。

設計判断

このPRでは、Rubocopのルールを盲目的に受け入れるのではなく、プロジェクトの方針に基づいて選択するアプローチが取られています。

特に Style/OneClassPerFile の無効化コメントには、「require にはコストがある」という技術的根拠が明記されています。パフォーマンスと保守性のバランスを考慮し、関連クラスを1ファイルにまとめる設計を継続しています。

一方で、コードの可読性向上につながる修正（String.new の削除、any?(Symbol) の使用、grep の活用）は積極的に取り入れられています。これらは既存のコードスタイルを変えることなく、表現をより簡潔にする改善です。

抑制されたルールはすべて common_rubocop_config.yml に集約され、チーム全体で共有される設定として管理されています。個別の判断ではなく、プロジェクト全体のポリシーとして明文化されている点が重要です。

まとめ

本PRは、Rubocopの新ルールに対して、プロジェクトの設計方針を維持しながら可能な改善を取り入れた変更です。ルールの機械的な適用ではなく、それぞれの背景を考慮した判断により、コードの品質とプロジェクトの一貫性の両立を実現しています。