将来的にすべてのソースコードがrubocopのlintに合格しないとmergeできないようにして、常にコーディング規約を満たした状態に持っていく。

方針¶

10年くらい前までやっていた行末endなどのコーディング規約は既に廃止しているが、一気にやるとdiffがえらいことになってblameなどで若干面倒になるので、少しでも編集したメソッドに関してだけ修正していっている。
雑に全部auto correctすると、相当なdiffが発生する。diffの量を小さくするため、次のようにファイルを優先度で分類し、やる価値が高いと判断したものにだけ適用する。

1. 優先度低: 何年もの間、全く開発者から参照されず、書き換えられていないファイル

• 古いコードほど今と異なる規約でコーディングされているので、diffが大きくなっていく傾向にある
• そもそも誰も読まないので、コーディング規約を守っていても違反していてもあんまり関係がない
• diffが大きいことからリグレッションの可能性が相対的に上がり、検証がだるい

2. 優先度高: 頻繁に開発者から参照され、書き換えが行われるようなファイル

• 歴史が浅いため、規約を適用しても小さなdiffですむ
• 書き換えが最近行われているので、直近で開発者が読む可能性が高く、コーディング規約を守る重要性が高い
• リグレッションが発生しても、最近修正した機能ならまだ覚えているので、修正が容易

手順¶

一気にやるとdiffがえらいことになってblameなどで若干面倒になるので、新規ファイルや著しい変更があったファイルに限定したい。
これを満たすために、rubocop対象のファイルをブラックリスト形式で管理する。ブラックリストは、作成した後は減らすことしかしないため、全体のエラー率は時間の経過とともに下がっていく。

ブラックリストは以下の条件で作成する:

• mikutter 4.1.0(rubocop導入したひとつ前のバージョン)で存在したすべてのファイル

今後、以下の条件を満たすものは即座にブラックリストから削除する:

• mikutter 4.1.0以降で50%以上の行が変更されたファイル(割合はいろいろ変えて様子を見て決定する)
  大幅にリファクタリングしたファイルなどはどうせdiffがでかくなっていてblameのとき邪魔なので、いっそのこと機械的にやってしまう

このIssueでやること¶

1. ブラックリストの作成
2. ブラックリストを除外したファイルのルールを検証する方法の確立
3. ブラックリストから除外対象となったファイルを除く方法の確立
4. 2を使ってコードをリファクタリングする

適用するバージョンは5.0（メンテナンスしている最も古いバージョン）にする。gtk3のコードに適用したいが、そうするとそれなりのdiffが発生してしまい、mergeが困難となることが予想されるため。

懸念¶

開発者が参照するコードは、頻繁に変更もされているはずだという前提に立っているが、なかには長い間変更されていないが参照されるコードというものも存在する。
この基準ではそういったコードをフォローできていない。

他の方法¶

rubocop todoは、コードの古さに応じてルールの適用方針を変えていく考え方とはあまり相性がよくなさそうなので、利用を断念した。