コードの明瞭度は、第一に主観的であり、第二に定量化できないものであることは一般的に受け入れられています。 さまざまな定量的コードメトリックがありますが、明確なメトリックはありません。 コードを知的に機械的に理解するには、そのセマンティック分析が必要です。これは人工知能のタスクです。
しかし、反対側から問題を見てみましょう。 他の人のコードを扱うとき、私たちは何をしますか？ コードを学習するプロセスはどうですか？ 関数をリーフスルーし、変数、クラスの定義を探し、関数から関数へ、ファイルからファイルへと進みます。
私が職場で行った最後の2つのタスクは、他の人のコードの分析と、その改善/書き換えのための推奨事項の発行に関連していました。 ファイルからファイルに切り替え、クラス、関数、および変数を調べて、それらの目的を理解しようとしただけです。
これから、コードの明瞭度を定量化する方法のアイデアが生まれました。 本質は非常に単純です。遷移とスクロールの数を測定し、コードの行数で正規化する必要があります。 関数の明瞭度を評価する場合、関数の行数で正規化します。 クラスについても、プロジェクト全体についても同様です。 このような評価によれば、一度スクロールダウンするのに十分なコードが理想的です。 または、極端な場合には、1つのメイン関数のみをスクロールするだけで十分です。 プログラムコードはプレーンテキストに似ている必要があります。プレーンテキストは、上から下に直線的に読み取られます。
以下に、このメトリックの要点を理解するのに役立ついくつかの例を示します。
例1 ：名前について何も語っていないコード（たとえば、j）で変数に遭遇します。 この変数の定義を見つけて（移行を行います）、運がよければ、その意味を説明するコメントがあります。 幸運でなく、コメントがない場合は、使用されているすべての場所を探し（移行を行い）、その目的を理解する必要があります。 そして、変数にコメントがあったとしても、おそらくすぐにそれを忘れてしまい、再びそれに戻る必要があります（遷移を行います）。
例2 ：コードで、空の名前の関数呼び出しに遭遇します。 さらに、関数がどのような結果を生成できるかは明確ではありません。 この関数の実装に移行し、何回か巻き戻して、その機能と結果が返されることを理解する必要があります。 また、関数の長さが200〜300行であることが判明した場合は、多くのスクロールが必要になります。
例3 ：分析された関数には、複数のネストがあります：サイクルの条件、条件のサイクル。 これをメモリに保持することは非常に難しく、定期的にスクロールしてコンテキスト全体をメモリに保持します。
例4 ：論理的に関連する関数は、ファイル全体にランダムに散在しているか、または他のファイルに配置されています。 そして、呼び出された関数の実装を見つけるために、リーフスルー、スイッチ、スイッチ、メモリからの考慮の現在のコンテキストを失う必要があります。
例5 （実際の作業からではなく、仮説的）：リファクタリングに熱心すぎる場合、各基本アクションを関数/クラスに選択し、それらをナビゲートすることもすべての合理的な制限を超える可能性があります。 多くのことを覚えておく必要があるため、コードの理解度も低下します。
したがって、メトリックには次の評価が含まれます。
- 変数、関数、クラスの名前
- 機能サイズ
- 入れ子
- ファイル内の関数のシーケンス
- ページ上の有用なコードの量を減らす過度のコメント
- パターンを使用する
このような了解度を評価する方法には主観がないわけではないという疑問を予見します。 同意します。 ここには2つの大きな問題があります。
まず、誰かがコードを頻繁にクリックすることに慣れている一方で、誰かがコンテキストを念頭に置くことができます。 それでも、この方法は意見に基づく単なる評価よりも客観的です。 そして、そのような評価の実施の容易さを考えると、結果を見るのは興味深いでしょう。
そして第二に、最初に、開発者は意図的にコードをより少ない（より多く）反転させて、望ましい評価を得ることができます。 しかし、そのような小切手が組織でよく知られた慣行になると、詐欺はなくなる可能性があります。
提案された方法では、コードのわかりやすさ（インターフェイスの品質を含む）のみを評価でき、アーキテクチャの品質、重複の欠如、依存関係などを評価できないことをすぐに確保したいと思います。 つまり、他のメトリックおよびコードアナライザーと組み合わせて使用することは理にかなっています。
これは、IDEのプラグインとして実装できます。