Visual Studio を使い、自分がクソコードを書いてしまっていないかをパっと確認する方法です。
Microsoft 公式に説明がありますが、ややこしかったり、手順通りやってもうまく行かなかったりするので、試した中で一番簡単だった手順を以下にまとめます。
ソースコードをいじってる Visual Studio のソリューションを起動。
Visual Studio のメニューから、ツール＞NuGet パッケージマネージャ＞ソリューションの NuGet パッケージの管理 を選択。
NuGet – ソリューションで『Microsoft.CodeAnalysis.Metrics』を検索
画像で示している順番に選択
インストールが終わったら、メニューから、分析＞Code Analysis の実行＞ソリューション を選択
デフォルトでは下ペインに『コードメトリックスの結果』ウィンドウが表示されます。
ソリューションに登録している全てのソースコードの「保守容易性指数」がグリーン ■ で表示されていれば、とりあえずＯＫです。
指標は６つしかないですが、その中の３つの指標を複合的に判定した結果が保守容易性指数です。
計算式も公式に記載されていますが、何らかの論拠があると思われます（論拠がないものは採用されません）。
ただ、グリーン判定が 20 ～ 100 と、かなり範囲が広いので、60 未満になったらバグチケットを発行し、60 以上になるまでタスクを終了できない…などのシステムを組むと良さそうです。
保守容易性指数を除いた５つの指標については、前述のリンク先に詳しく記載されていますので、ここでは要点だけを記載します。
コードがこんがらがっていると数字が大きくなるので、低くなるように構造を見直す。
10 以下に抑えるのが良い。
10 を超える場合は、その必要性を完全に理解していて、かつ、完璧なテストを行える状態ならOK。
⇒ Microsoft 公式による詳しい説明
浅く（数字を小さく）する。
⇒ Microsoft 公式による詳しい説明
可能な限り結合を少なく（数字を小さく）する。
最大でも９以下に抑える。
可能な限り数字を小さくする。
空白行もカウントされるので、あまりあてにならない。
行数を抑えるために、他の指標に悪影響を与えないように注意する。
ソースコードの分かりやすさは保守のしやすさに直結するので、そのために行数が増えてしまうのは構わない。
ただし、分かりやすさや、理解度は人によって差があるので、客観的な判断がしにくい。
IL（.Net用の中間言語）をベースとした（機械語ではない）ランタイム用コードの行数。
ソースコード行数が少なくても、コンパイル後の行数が膨れ上がることがある。
C++ の template を多用したりなどで増える。
私はコードレビューがコードの品質を高めるとは思いません。
正確に言うと、コスパが悪いです。
ほとんどの場合、学習目的でしか機能しないと思います。
学習目的なのであれば、学習用の時間を確保して、その時間内でやるべきです。
コードレビューが本当に必要な状況はかなり限定的で、重大な不具合を修正するとき、あるいは、扱いが難しいセンシティブな部分の実装や修正をするとき、新人やその環境に不慣れな経験者の教育期間中くらいだと思います。
コードレビューは、レビュー担当者の能力と主観に寄ってしまうので、役立つ場合もあれば、逆に働く場合もあります。
コードの質を高めたいのであれば、コード解析アプリなどを使った客観的な手法を取る必要があります。
チームでコードを共有するためにコードレビューを行う…といった場合もありますが、効果が薄いと思っています。
それよりも、１つの実装タスクを複数人でローテーションしたり（ペアプログラミングに近いです）、バグ修正を実装者とは別の人に振る方がコードを共有するという意味では効果が高いと思います。
振られた人はコードレビューをするときよりも真剣に取り組まないといけなくなるためです。
一番の問題は、コードレビューには時間がかかり、レビューを待っている間タスクが保留状態になるため対応が遅れ、その後のワークフローに悪い影響を与えることです。
開発後期の工数が厳しい状況ではコードレビューによって納期が遅れるため悪影響しかありません。