Claude Codeを使った命名規則チェックと一括修正の注意点

Claude Codeで命名規則を統一する前に押さえること

Claude Codeで命名規則を統一するなら、最初に決めるべきことは「どの名前を、どの基準で、どこまで直すか」です。

命名は見た目の好みだけではなく、コードの読みやすさ、レビューのしやすさ、検索のしやすさ、保守のしやすさに関わります。

Claude Codeは命名のばらつきを見つけたり、修正案を出したりするのに役立ちますが、プロジェクトの方針そのものを何も決めずに任せると、かえって判断が揺れやすくなります。

命名規則を統一する重要性

命名規則がそろっているコードは、変数や関数の役割を読み取りやすくなります。

たとえば同じユーザーIDを表す名前がuserId、userID、uidのように混在していると、同じ意味なのか別の意味なのかを確認する手間が増えます。

この小さな迷いが積み重なると、レビュー時の指摘が増えたり、検索しても必要な箇所を見つけにくくなったりします。

命名規則を統一しておくと、開発者同士の認識がそろいやすくなります。

Claude Codeに修正やレビューを依頼するときも、判断基準が明確なほど安定した提案を受けやすくなります。

つまり命名規則は、人間のためだけでなく、Claude Codeに正しく作業してもらうための前提にもなります。

Claude Codeで統一できる命名対象

Claude Codeで確認しやすい命名対象は、変数名、関数名、クラス名、コンポーネント名、ファイル名、ディレクトリ名などです。

プロジェクトによっては、DBカラム名、APIエンドポイント名、設定キー、環境変数名、テスト名も対象になります。

ただし、すべてを同じ強さで変更してよいわけではありません。

内部だけで使う変数名は比較的修正しやすい一方で、外部に公開しているAPI名やDBカラム名は影響範囲が広くなります。

Claude Codeには「違反箇所を探す」「修正候補を出す」「影響範囲を整理する」といった作業を任せると安全です。

いきなり全体を一括変更するより、まずは対象を分けて確認するほうが失敗を避けやすくなります。

先に決めておきたいチームの前提

命名規則をClaude Codeに伝える前に、既存のルールやチームの合意を確認しておきます。

言語やフレームワークによって、自然な命名の形は変わります。

JavaScriptやTypeScriptではcamelCaseがよく使われますが、CSSのクラス名やファイル名ではkebab-caseが選ばれることもあります。

ReactコンポーネントではPascalCaseを使うなど、対象によって慣習が分かれる場合もあります。

チームで開発している場合は、個人の好みではなく、既存コードとレビュー方針に合わせることが大切です。

命名規則の目的は、すべての名前を機械的に同じ形にすることではありません。

プロジェクト内で迷いにくく、読み手にとって意味が伝わりやすい状態を作ることが目的です。

CLAUDE.mdに命名ルールを書く方法

Claude Codeで命名規則を継続的に使うなら、CLAUDE.mdにルールを書いておくと便利です。

その場限りのプロンプトで毎回説明するより、プロジェクト共通の前提として残しておくほうが、修正やレビューのたびに同じ基準を使いやすくなります。

CLAUDE.mdには、抽象的な方針だけでなく、対象、形式、例外、良い例、避けたい例まで書くのがポイントです。

CLAUDE.mdに書くべき基本項目

CLAUDE.mdには、まず命名規則の対象範囲を書きます。

たとえば「変数名はcamelCase」「ReactコンポーネントはPascalCase」「ファイル名はkebab-case」のように、対象ごとに分けると判断しやすくなります。

次に、boolean変数、関数名、略語、ファイル名、DBカラム名など、表記ゆれが起きやすい項目を追加します。

禁止したいパターンも書いておくと、Claude Codeが検出しやすくなります。

たとえば「tmpやdataのような意味が広すぎる名前は避ける」「略語は既存ルールにあるものだけ使う」といった形です。

例外がある場合は、例外も明記しておきます。

例外を書かずに運用すると、Claude Codeが正しい名前まで機械的に変更しようとすることがあります。

良い例と悪い例をセットで書く

命名規則は、文章だけで説明するより、良い例と悪い例をセットで書くほうが伝わりやすくなります。

たとえばboolean変数なら、isActive、hasPermission、canEdit、shouldRetryのように、意味ごとに接頭辞を分けて示します。

避けたい例としてactiveFlag、permissionCheck、editAbleのような曖昧な名前を置くと、Claude Codeが違反を判断しやすくなります。

関数名なら、getUserProfile、createInvoice、validateEmailのように動詞から始める例を示します。

悪い例としてuserProfile、invoiceCreate、emailValidationのような名前を置くと、関数なのか値なのかが分かりにくいことを説明できます。

良い例と悪い例は、チーム内のレビューでも役立ちます。

判断に迷ったときに、具体例へ戻って確認できるからです。

曖昧な指示を避けるコツ

CLAUDE.mdには「わかりやすい名前にする」「自然な名前にする」といった抽象的な指示だけを書かないようにします。

このような指示は方向性としては正しいものの、実際の修正では判断が分かれます。

Claude Codeに安定してチェックしてもらうには、条件を具体化する必要があります。

たとえば「boolean変数は状態ならis、所有ならhas、権限ならcan、実行判断ならshouldを使う」と書くと、判断基準が明確になります。

「略語はid、url、apiなどプロジェクトで許可したものだけ使う」と書けば、不要な略語を減らせます。

「既存の公開API名とDBカラム名は、変更前に影響範囲を確認する」と書いておけば、自動修正のしすぎも防ぎやすくなります。

Claude Codeに伝えるルールは、短くても具体的であることが大切です。

変数名・関数名の命名をそろえる

変数名と関数名は、コードを読むときに最も目に入りやすい部分です。

そのため、命名規則の統一効果が出やすい一方で、表記ゆれも起きやすい場所です。

Claude Codeを使うと、似た意味の名前や不自然な名前を洗い出し、ルールに沿った修正候補を出しやすくなります。

boolean変数の命名を統一する

boolean変数は、trueまたはfalseを表すため、名前だけで状態や条件が分かることが重要です。

よく使われる接頭辞には、is、has、can、shouldなどがあります。

isは状態を表すときに使いやすく、isActiveやisVisibleのような名前に向いています。

hasは所有や存在を表すときに使いやすく、hasPermissionやhasErrorのような名前に向いています。

canは権限や可能性を表すときに使いやすく、canEditやcanSubmitのような名前に向いています。

shouldは処理すべきかどうかの判断に使いやすく、shouldRetryやshouldShowModalのような名前に向いています。

Claude Codeには、boolean変数だけを対象にして「接頭辞が意味に合っているか確認してください」と依頼すると、レビューしやすい形で改善点を出せます。

関数名を動詞から始める

関数名は、何をする処理なのかが分かるように、動詞から始めると読みやすくなります。

たとえば、ユーザー情報を取得する関数ならgetUserProfile、請求書を作成する関数ならcreateInvoice、メールアドレスを検証する関数ならvalidateEmailのようにします。

関数名が名詞だけになっていると、値なのか処理なのかが分かりにくくなります。

Claude Codeに依頼するときは「関数名が動詞から始まっているか確認し、処理内容に合う動詞を提案してください」と伝えるとよいです。

ただし、フレームワークやライブラリの慣習で決まっている名前は無理に変えないほうが安全です。

命名規則は、既存の技術スタックに合わせて運用する必要があります。

変数名の表記ゆれを修正する

変数名の表記ゆれは、同じ意味の名前が複数の形で使われることで起きます。

たとえばuserId、userID、uidが同じ意味で混在していると、検索や置換が難しくなります。

Claude Codeには、まず「同じ意味で使われている可能性がある変数名を一覧化してください」と依頼すると安全です。

いきなり置換するのではなく、候補を確認してから修正方針を決めます。

表記ゆれを直すときは、既存コードで最も多く使われている形、言語の慣習、外部APIとの整合性を見ます。

内部変数なら統一しやすいですが、APIレスポンスのキーやDBカラム名と結びつく名前は慎重に扱います。

Claude Codeの提案は便利ですが、同じ単語に見えても意味が違う場合があります。

そのため、修正前に用途と参照箇所を確認することが大切です。

略語の使用ルールを決める

略語は短く書ける一方で、意味が伝わりにくくなることがあります。

id、url、apiのように一般的な略語は使いやすいですが、独自の略語を増やしすぎると新しいメンバーが理解しにくくなります。

Claude Codeに命名規則を確認させる場合は、許可する略語と避ける略語をCLAUDE.mdに書いておきます。

略語を完全に禁止する必要はありません。

重要なのは、チーム内で意味が共有されている略語だけを使うことです。

迷う略語が出たら、その場で判断せず、CLAUDE.mdへ追記して次回以降の基準にします。

ファイル名・ディレクトリ名・DB/API名を統一する

命名規則はコード内の変数や関数だけでなく、ファイル名、ディレクトリ名、DBカラム名、API名にも関係します。

これらの名前がそろっていると、プロジェクト全体の構造を把握しやすくなります。

ただし、コード内の名前より影響範囲が広い場合もあるため、修正前の確認が重要です。

ファイル名とディレクトリ名を統一する

ファイル名やディレクトリ名は、プロジェクトの見通しに大きく影響します。

たとえばコンポーネント名はPascalCase、通常のユーティリティファイルはkebab-case、テストファイルは対象ファイル名に.testを付けるなど、役割ごとに決めておくと探しやすくなります。

Claude Codeには「このディレクトリ内のファイル名が命名規則に沿っているか確認してください」と依頼できます。

ただし、ファイル名を変えるとimportパスや設定ファイルにも影響することがあります。

そのため、ファイル名の変更は、参照箇所の確認とセットで進めます。

単純な表記ゆれに見えても、ビルド設定やルーティング規約と関係している場合があります。

DBカラム名やAPI名も統一する

DBカラム名やAPI名の命名は、コード内の変数名より慎重に扱う必要があります。

DBカラム名を変更すると、マイグレーション、既存データ、クエリ、管理画面、外部連携に影響することがあります。

API名を変更すると、フロントエンド、外部利用者、ドキュメント、テストにも影響が出る可能性があります。

Claude Codeには、DBカラム名やAPI名を直接変更させる前に、影響範囲を洗い出してもらうと安全です。

「変更候補だけを出し、実際の変更は行わないでください」と明記すると、レビューしやすくなります。

このように対象ごとにリスクを分けると、Claude Codeへの依頼も具体的になります。

言語やフレームワークごとの慣習を優先する

命名規則を統一するといっても、すべての名前を同じ表記にする必要はありません。

言語やフレームワークには、それぞれ自然な命名の慣習があります。

たとえばJavaScriptの変数名はcamelCaseが自然でも、CSSのクラス名やURLパスはkebab-caseのほうが読みやすい場合があります。

ReactコンポーネントではPascalCaseが一般的に使われます。

DBではsnake_caseが使われるプロジェクトもあります。

Claude Codeに依頼するときは「このプロジェクトの技術スタックに合う命名を優先してください」と伝えると、無理な統一を避けやすくなります。

統一とは、全部を同じ形式にそろえることではありません。

対象ごとに自然な形式を決め、その範囲内でぶれをなくすことです。

変更してよい名前と慎重に扱う名前を分ける

命名規則を整えるときは、変更してよい名前と慎重に扱う名前を分けます。

ローカル変数や内部関数は比較的変更しやすい対象です。

一方で、外部公開API、DBカラム、環境変数、設定キー、ログに出る識別子は慎重に扱う必要があります。

Claude Codeには「変更してよい候補」と「影響確認が必要な候補」を分けて出してもらうと便利です。

この分け方をしないまま一括修正すると、動作は通っても外部連携や運用に問題が出ることがあります。

特に本番環境で使われている名前は、コード上の検索だけでは影響範囲を把握できない場合があります。

安全に進めるには、まず一覧化し、次に影響範囲を確認し、最後に小さく修正します。

命名規則チェック用のプロンプト例

Claude Codeに命名規則を確認してもらうときは、依頼文を分けると安全です。

最初から修正まで任せるのではなく、検出、修正案、差分確認の順に進めると、意図しない変更を減らせます。

命名規則チェックでは、何を基準に見るのか、どこまで変更してよいのか、出力形式をどうするのかを明確にします。

命名規則に違反している箇所を探すプロンプト

最初は、修正ではなく検出だけを依頼します。

たとえば次のように伝えます。

• このプロジェクトのCLAUDE.mdに書かれた命名規則に沿って、変数名、関数名、ファイル名の表記ゆれを確認してください。
• まだ修正は行わず、違反している可能性がある箇所、理由、修正候補を一覧で出してください。
• DBカラム名、公開API名、環境変数名は影響範囲が広いため、変更候補として分けて表示してください。

このように「まだ修正しない」と明記すると、予想外の変更を避けやすくなります。

検出結果を見てから、修正する範囲を決めるほうが安全です。

修正案だけを出してもらうプロンプト

違反箇所が分かったら、次に修正案だけを出してもらいます。

たとえば次のように依頼します。

• 検出した命名規則違反について、修正案だけを出してください。
• 既存コードはまだ変更しないでください。
• 変更前の名前、変更後の名前、変更理由、影響しそうなファイルを表で整理してください。

この依頼にすると、レビュー担当者が内容を確認しやすくなります。

Claude Codeが出した修正案の中には、意味が近いだけで実際には別の役割を持つ名前が含まれる場合があります。

そのため、修正案は必ず人が確認します。

特にDBカラム名やAPI名は、コード上の整合性だけで判断しないようにします。

差分を確認しながら修正するプロンプト

修正案を確認したら、最後に差分を確認しながら反映します。

たとえば次のように依頼します。

• 承認した命名変更だけを対象に、最小限の差分で修正してください。
• 修正後に、変更したファイル、変更した名前、確認すべきテストを一覧で出してください。
• 影響範囲が広い変更は、別PRに分ける前提で提案してください。

このように伝えると、Claude Codeが必要以上に広い修正をするリスクを減らせます。

差分が大きくなる場合は、変数名だけ、関数名だけ、ファイル名だけのように分けて進めます。

一度に大量の名前を変えると、レビューが難しくなります。

命名規則の統一は、見た目を整える作業でありながら、実際にはリファクタリングに近い影響を持つ場合があります。

Claude Codeに丸投げしないための確認ポイント

Claude Codeは命名候補を出すのが得意ですが、プロジェクト固有の背景を完全に理解しているとは限りません。

そのため、丸投げではなく、確認ポイントを決めて使うことが大切です。

確認したいのは、名前の意味が変わっていないか、参照箇所が漏れていないか、外部仕様に影響しないか、テストで確認できるかです。

また、命名をそろえることでコードが読みにくくなっていないかも見ます。

たとえば短い名前をすべて長くすればよいわけではありません。

スコープが狭い一時変数なら、短い名前のほうが自然な場合もあります。

Claude Codeの提案を採用するかどうかは、最終的に人が判断します。

Pull Requestで命名規則チェックを自動化する

命名規則の統一は、一度だけ実施して終わりではありません。

新しいコードが追加されるたびに、少しずつ表記ゆれが増えることがあります。

そのため、Pull Requestの流れに命名チェックを組み込むと、継続的に品質を保ちやすくなります。

PR前にClaude Codeでセルフチェックする

PRを出す前に、Claude Codeで命名規則のセルフチェックを行うと、レビュー時の指摘を減らせます。

依頼文は「今回の差分だけを対象に、CLAUDE.mdの命名規則に違反している箇所を確認してください」のようにします。

差分だけに限定すると、既存コード全体の問題に話が広がりにくくなります。

レビュー前に表記ゆれを見つけられれば、レビュアーは設計や仕様の確認に集中しやすくなります。

セルフチェックは、開発者自身が命名ルールを意識するきっかけにもなります。

毎回同じ指摘が出る場合は、CLAUDE.mdのルールが曖昧か、チーム内で合意できていない可能性があります。

レビュー観点として命名規則を入れる

PRテンプレートに命名規則の確認項目を入れると、チェック漏れを防ぎやすくなります。

たとえば「変数名・関数名はCLAUDE.mdの命名規則に沿っているか」「boolean変数は意味に合う接頭辞を使っているか」「公開APIやDB名の変更がある場合は影響範囲を確認したか」といった項目です。

このようなチェック項目があると、レビュアーによって見る観点が変わりにくくなります。

命名規則の指摘は、好みの押し付けになりやすい部分でもあります。

事前にルール化しておくことで、個人の感覚ではなくチームの基準としてレビューできます。

Claude Codeのチェック結果をPRに添える運用にしてもよいです。

ただし、チェック結果をそのまま正解扱いにせず、必要に応じて人が判断します。

自動化できる部分と人が見る部分を分ける

命名規則チェックには、自動化しやすい部分と人が見るべき部分があります。

表記形式の違い、禁止略語、boolean変数の接頭辞などは、比較的自動化しやすい項目です。

一方で、その名前が業務上正しい意味を表しているか、ドメイン知識に合っているか、将来の拡張に耐えられるかは人の判断が必要です。

Claude Codeには、機械的に見つけやすい違反を洗い出してもらいます。

人は、意味や設計に関わる判断を確認します。

この分担を決めておくと、AIの提案を過信せずに活用できます。

自動化の目的は、人の判断をなくすことではありません。

人が見るべき重要な部分に集中できるようにすることです。

チームで迷った命名を記録する

レビュー中に迷った命名は、その場限りの会話で終わらせないようにします。

同じ迷いが繰り返される場合は、CLAUDE.mdに追記する価値があります。

たとえば「取得系はgetで統一するのかfetchを使うのか」「権限確認はcanを使うのかhasPermissionを使うのか」といった迷いです。

判断が決まったら、ルールと例をセットで残します。

これにより、次回からClaude Codeにも同じ基準で確認してもらいやすくなります。

命名規則は、最初から完璧に作るものではありません。

実際のレビューや実装で出た迷いを少しずつ反映して、使いやすいルールに育てていきます。

一括リネーム時の注意点

命名規則を統一しようとすると、既存コードをまとめて直したくなることがあります。

しかし、一括リネームは影響範囲が広く、参照漏れや外部連携の破壊につながることがあります。

Claude Codeを使う場合でも、検出、確認、分割修正、テストの順番を守ることが大切です。

影響範囲を先に洗い出す

一括リネームの前には、影響範囲を先に洗い出します。

確認する対象は、コード内の参照箇所だけではありません。

テスト、設定ファイル、ドキュメント、DBマイグレーション、API仕様、ログ、監視設定、外部連携も確認します。

Claude Codeには「この名前を変更した場合に影響する可能性がある箇所を一覧化してください」と依頼できます。

この段階では、まだ変更しないほうが安全です。

影響範囲が分かれば、変更を小さく分ける判断もしやすくなります。

特にDBカラム名や公開API名は、コード検索だけでは利用箇所を把握できない場合があります。

外部に公開している名前は、互換性や移行期間も考える必要があります。

小さな単位で変更する

命名規則の修正は、小さな単位で進めるほうが安全です。

たとえば最初はboolean変数だけ、次に関数名だけ、最後にファイル名を見直すように分けます。

一度に大量の名前を変えると、差分が大きくなり、レビューで意味のある確認がしにくくなります。

Claude Codeには「今回はboolean変数だけを対象にしてください」のように範囲を明確に指定します。

変更対象を絞ると、テストで確認すべき範囲も分かりやすくなります。

小さく直すことは、作業量を増やすためではありません。

問題が起きたときに原因を特定しやすくするためです。

命名規則の統一は、見た目の整理であっても、変更としては慎重に扱う必要があります。

自動修正を過信しない

Claude Codeの自動修正は便利ですが、すべての提案がプロジェクトに合うとは限りません。

同じ単語を含む名前でも、文脈によって意味が違うことがあります。

たとえばuserIdとaccountIdが似た用途に見えても、業務上は別の概念かもしれません。

自動修正をそのまま反映すると、名前の意味が変わったり、既存の仕様とずれたりする可能性があります。

そのため、Claude Codeには変更前後の対応表を出してもらい、人が確認してから反映します。

テストが通っても、命名として適切とは限りません。

特に業務用語やドメイン用語は、チーム内の意味づけを確認する必要があります。

AIに任せる部分と、人が責任を持つ部分を分けることが重要です。

既存コードとの互換性を確認する

名前を変えるときは、既存コードとの互換性を確認します。

内部変数なら影響は限定的ですが、公開API、DBカラム、環境変数、設定キーは互換性の問題が起きやすいです。

外部システムがその名前を参照している場合、コード内だけを修正しても不十分です。

API名を変える場合は、古い名前をしばらく残す、移行期間を作る、ドキュメントを更新するなどの対応が必要になることがあります。

DBカラム名を変える場合は、マイグレーション、既存データ、ロールバック手順も確認します。

Claude Codeには、互換性に関わる可能性がある名前を分けて出してもらうと役立ちます。

変更してよい名前と、設計判断が必要な名前を混ぜないことが大切です。

向いていないケースも知っておく

命名規則の一括修正が向いていないケースもあります。

短期の検証コードや捨てる予定のプロトタイプでは、細かい命名統一に時間をかけすぎる必要はありません。

チーム内で命名方針が合意されていない段階でも、一括修正は避けたほうが安全です。

公開APIやDB設計の影響範囲を確認できない状況で、Claude Codeに一括変更を任せるのも危険です。

まずはルールを決め、検出だけ行い、変更対象を絞るところから始めます。

命名規則の統一は、急いで一気に終わらせる作業ではありません。

安全に継続できる形で進めるほうが、結果的に保守しやすいコードになります。

命名規則を継続的に改善する

命名規則は、一度決めたら終わりではありません。

プロジェクトが大きくなったり、新しい技術を導入したりすると、以前のルールだけでは判断しにくい場面が出てきます。

Claude Codeを使う場合も、運用しながらルールを見直すことで、より使いやすい命名規則になります。

運用中に出た迷いをCLAUDE.mdへ追記する

レビューや実装中に迷った命名は、CLAUDE.mdへ追記します。

たとえば「取得処理はgetとfetchのどちらを使うか」「削除済み状態はisDeletedとdeletedAtのどちらで表すか」などです。

一度判断した内容を残しておけば、次回から同じ議論を減らせます。

Claude Codeにとっても、判断材料が増えるため、提案が安定しやすくなります。

追記するときは、ルールだけでなく例も残します。

例があると、人もAIも判断しやすくなります。

例外ルールを増やしすぎない

命名規則を細かくしすぎると、かえって運用が難しくなります。

例外が増えすぎると、開発者が毎回ルールを確認しなければならなくなります。

Claude Codeにとっても、例外が多いルールは判断が難しくなります。

ルールを追加するときは、本当に繰り返し起きる迷いなのかを確認します。

一度だけ出た特殊なケースまで細かくルール化すると、CLAUDE.mdが読みにくくなります。

基本ルールはシンプルに保ち、例外は必要最小限にするのが続けやすい運用です。

定期的に命名規則を見直す

命名規則は、定期的に見直すと実態に合いやすくなります。

新しいフレームワークを導入したときや、ディレクトリ構成を変えたときは、命名ルールも調整が必要になることがあります。

古いルールが残っていると、Claude Codeが現在の実装方針に合わない提案をする場合があります。

見直しでは、使われていないルール、曖昧なルール、例外が多すぎるルールを整理します。

チームで使っている言葉が変わった場合も、命名規則に反映します。

ルールは増やすだけでなく、削ることも大切です。

命名規則は開発習慣として定着させる

命名規則は、ドキュメントに書いただけでは定着しません。

PR前のセルフチェック、レビュー観点、Claude Codeへの確認、CLAUDE.mdへの追記をセットで回す必要があります。

毎回の開発フローに組み込むことで、命名のばらつきは少しずつ減ります。

新しく参加したメンバーにとっても、命名規則が整理されているとプロジェクトを理解しやすくなります。

Claude Codeを使えば、ルールの確認や表記ゆれの検出を習慣化しやすくなります。

ただし、最後に判断するのはチームです。

AIの提案をきっかけにしながら、チームに合う命名文化を育てることが重要です。

まとめ

Claude Codeで命名規則を統一するには、ルールを決め、CLAUDE.mdに書き、チェック用プロンプトで確認し、PRやレビューに組み込む流れが大切です。

変数名や関数名だけでなく、ファイル名、DBカラム名、API名まで対象にすると、プロジェクト全体の一貫性を高めやすくなります。

一方で、影響範囲が広い名前は慎重に扱う必要があります。

まずはCLAUDE.mdとチェックプロンプトから始める

最初から全体を一括修正する必要はありません。

まずはCLAUDE.mdに命名規則を書き、Claude Codeへ検出だけを依頼するところから始めると安全です。

次に、修正案を確認し、小さな単位で反映します。

この順番なら、命名規則を整えながら、予期しない変更を減らせます。

命名規則は継続運用してこそ効果が出る

命名規則は、一度そろえて終わりではありません。

新しい実装やレビューのたびに、迷った命名をCLAUDE.mdへ戻し、チームの基準として育てていくことが大切です。

Claude Codeは、その運用を助けるための道具として使うと効果的です。

ルール作成、チェック、レビュー、改善をつなげれば、命名のばらつきが減り、読みやすく保守しやすいコードに近づきます。