Entropyの概念を使用して、ソースコードを便利な方法で分析できますか？
複雑さの相対的な値を生成するルールを含む静的ソースコード分析のコンテキストを定義できるのは、私には当然のことのようです。ソースコードには「エネルギー」がないため、物理的な意味ではそうではないことはわかっていますが、リートアカデミックでは、類似点を描くための努力があったに違いありません。これについて何か知っている人はいますか。そうであれば、どのような目的で有用な結果が得られましたか？
コードの複雑さの測定値はすでにいくつかあります。
- 循環的複雑度
- クラスの長さ
- メソッドの長さ
- フィールド数
- メソッドパラメータの数
- Nパスの複雑さ
- ファンインとファンアウト
- データフロー分析（DU/DDチェーン）
これらを欠陥密度、維持するための努力、および理解の容易性に関連付ける作業が行われました。分析から何を学ぼうとしているのかに応じて、他のものより意味のあるものもあります。私は物理学のエントロピーの概念にそれほど精通していませんが、私が時間の経過とともに名前を付けたもののような測定値とメトリックを追跡し、それらを時間の経過に伴う欠陥に関連付けることは、あなたが探しているものに似ているのだろうかと思います。
Ivar Jacobsonのソフトウェアエントロピーの定義 および software rot にも興味があるかもしれません。これらのトピックの一般的な考え方は、コードと実行環境が変化するにつれて、ソフトウェアシステムが劣化し始めることです。リファクタリングは、エントロピーや腐敗を最小限に抑える方法と見なされ、少なくとも私の経験では、上で述べたメトリックと測定は、システムまたはサブシステムでリファクタリングが必要になる可能性があることを示す指標になります。
熱力学的エントロピーと「複雑さ」の間の類似点を描こうとしていると思います。実は、エントロピーはdisorderではなくcomplexityの尺度です。この2つが同等で互換性があるとは思いません。
熱力学エントロピーに最も近いアナログは、ランダム変数の無秩序の量を測定するShannon entropyです。この概念は、主にメッセージ内の「情報」の量に関係しています。
その点で、1つのコードは多くの情報（高いエントロピー）を持つことができますが、複雑度は非常に低くなります。非常に長い任意の文字列を単純に出力するプログラムを考えてみてください。情報は豊富ですが、複雑度は低くなっています。
エントロピー は、「障害[または]予測不能性の尺度」です。情報に含まれる固有のパターンの範囲が広い（つまり、「大まかに」という意味）と、エントロピーの度合いが高くなります。
コンピューターのソースコードに適用すると、この原則は役立つと思います。ただし、エントロピーを計算するための確率モデルソースコードの場合を設計する必要があります。 （すぐに頭に浮かぶデータ構造は、さまざまなEdgeタイプ（呼び出し、クラス継承など）を持つグラフです。）
モデルが設計され、ソフトウェアアプリケーションのソースコード（つまり、ノード/エッジの周波数）が入力されると、エントロピーが計算されます。
私はこれに関する研究を知りませんが、私の直感は、エントロピーの程度が低いと、ソースコードがアプリケーション全体で共通のパターンを再利用することを意味する（つまり、 [〜＃〜] dry [〜＃〜]） ）。逆に、高度なエントロピーは、ソースコードの複雑さが高く、十分に因数分解されていないことを意味します。
エントロピーについて考える方法の1つは「得られる平均的な情報」なので、モデリング情報に戻った方がいいと思います。情報を数学的にモデル化するための2つの基本的なアプローチを知っています。 （ウィキペディアへの参照を提供してくれて恐縮ですが、私見では悪くありません。）
Shannon Information ：シンボルセット、それらの確率分布、シンボルセット間で情報を転送できるコード、およびそれらのコードの長さを調べます。コード効率、ノイズ、エラー検出、冗長性による訂正などの一般的な概念は、シャノン情報理論の観点から説明されています。情報を表現する1つの方法は、シンボルを表すことができる最短のバイナリコードの長さであると言うことです。これは確率に基づいています。確率は、オブザーバーによってシンボルまたはイベントに割り当てられた数値です。
Solomonoff （または Kolmogorov ）情報。 これは別の説明です。 この定式化では、シンボルまたはイベントの情報内容は、それを計算できる最も短いプログラムの長さで表されます。ここでも、オブザーバーが確率を割り当てるのではなく、プログラムを実行できる汎用マシンに関連しています。すべてのユニバーサルマシンはユニバーサルチューリングマシンでシミュレーションできるため、ある意味では、シンボルまたはイベントの情報内容は相対的ではなく絶対的です。
これが日常的に何を意味するのか、つまり 私が本を書いた について自由に語ることができる場合、それは単に、関数の仕様や言語は一定に保たれ、コメントや名前の長さなどが適切に考慮されています。しかし、これには問題があります。「APLターピット」では、簡潔さは理解できないことと同じです。
（AIの研究中に行ったように）プログラムの機能仕様は、現実的であるだけでなく、効率的にエンコードされた、つまり要件についての考え方を変えるほど十分に冗長性のないメンタルモデルで構成されることを検討することをお勧めします。内部的に矛盾する、つまり「バグ」が発生する危険を冒すことなく実行できます。次に、プログラミングのプロセスは、メンタルモデルを入力として受け取る情報チャネルであり、その出力は実際のソースコードです。次に、メンタルモデルに変更が加えられた場合、そのデルタはプログラミングプロセスを通じて供給され、ソースコード内の対応するデルタに変換される必要があります。そのデルタは簡単に測定できます。そのデルタを適用する前と適用した後（完全に、すべてのバグが解決された）の間でソースを比較し、挿入、削除、および置換されたコードブロックの数をカウントします。つまり、ソースコード言語がメンタルモデルを表す言語をよりよく表します（名詞、動詞、および構造に関して）。その測定値が関数変更の可能性のある領域で何らかの形で平均化されている場合、それはソース言語のエントロピーの概念であり、少ないほど優れています。これには用語があります- ドメイン固有言語（DSL）
参照が弱い/個人的である場合は申し訳ありませんが、この全体的な質問は非常に重要なものだと思います。
Jon Jagger と Olve Maudal は、2011年のAccuカンファレンスセッションで見ることができるように、コードエントロピーの見方が少し異なります コードエントロピーとソフトウェアの物理学 =。
彼らは、コードの安定性が将来の開発者/メンテナがそのコードを変更する可能性があるかどうかに関係していることについて話します。
これを実証するために、彼らは多数のコードスニペットを使用して調査を行い、結果は非常に興味深いものでした。
- one-true-braceスタイル に対して強いバイアスがあるようです。
- しかし、を受け入れる単一のステートメントifの強いバイアス。
- 一時変数の使用に対して強いバイアスがありました。
- 演算子の優先順位を明確にするために括弧を追加することには強いバイアスがありました。
プラス16人。
一般的な傾向は、コードを理解しやすくし、誤解しにくくすることです。
また、何年にもわたって大規模なコードベースに加えられたいくつかの変更についても見ていきます。
スライド自体はセッションの筆記録にならないという欠点がありますが、そこにはいくつか興味深い点があります。
プログラムの複雑さの尺度としてエントロピーを使用した 教授 の下で勉強しました（私たちのテキストは これ 、彼のパブのいくつかは ここ ）です。 FAUには多くの学位論文がありましたが、これは主要な対策の1つでしたが、学校のWebサイトは前回見た後で変更されており、学生の学位論文が現在どこにあるのかを見つけることができません。
そのような論文の1つは 情報理論とソフトウェア測定 です。
エントロピーと同じように「数学的」である定義が必要な場合は、コルモゴロフの複雑度を確認することをお勧めします。これは、何かが実行される可能性のある最小限のコードで複雑度を測定します。ただし、これはコードの複雑度ではありません。しかし、コードで何をしようとしているのか。ただし、理論的には特定のコードを最小のコードと比較できるため、これは適切だと考えるかもしれません。ただし、これは現在、実際のコードの複雑さを測定するための有用な手法ではありません。
これは現実的ではないと思います。よく書かれたコードベースは、より高いエントロピー（無秩序）を持つべきだと主張できます。コードスニペットが何度も繰り返されるコードベースを考えてください。繰り返し部分（低いエントロピー/ファイルサイズ）のため、高い圧縮率で圧縮できますが、コードを別の関数に移動すると、圧縮率は低くなります（より高いエントロピー/ファイルサイズ）。
ですから、コードの品質を測定するために、圧縮率を係数として使用してEntropy/CodeLinesのようなものを計算できますが、これには、ランダム入力の合計が世界最高のコードのように見えるという問題が明らかにありません。
確かに、圧縮率はコードのエントロピーを測定するのに適したメーターですが、どちらもコード品質の良いメーターではありません。
エントロピーという用語は、熱力学や情報理論だけでなく、データ圧縮の現実の世界でも使用されています。そのコンテキストでは、コンプレッサーが見るエントロピーは、コンプレッサーが生成するビット数と同じです。 （エントロピーと見なされるものは、コンプレッサーが入力データを記述するために使用するモデルに依存するため、「コンプレッサーが見るエントロピー」と言ったことに注意してください。これが、さまざまなコンプレッサーがさまざまなサイズのファイルを生成する理由です。一方にエントロピーとなるものは、もう一方に悪用可能な構造です。）
これは、原則として、ソースコードの複雑さに美しく適用できます。完全に標準に準拠したソースコードでのみ機能し、コンパイラーと同じように実際に解析して対応する構文ツリーを生成するコンプレッサーを「ただ」作成します。次に、この構文ツリーをたどり、各ノードで各ポイントで可能なノードを決定し、そのノードをその知識でエンコードします。
したがって、たとえば、言語で既存の識別子、かっこで囲まれたもの、または特定の時点での製品のいずれかが許可されている場合、コンプレッサーはタイプ情報を考慮して、可能な既存の識別子をカウントします（このような識別子が3つあるとしましょう） ）、可能な2つの部分式に2を追加して、5つの可能性を与えます。したがって、ノードはlb 5 = 2.32ビットでエンコードされます。 2つの可能な部分式の場合、それらの内容をエンコードするためにより多くのビットが必要になります。
これは、実際のコードの複雑さを非常に正確に測ることができます。 ただし、この測定値はまだ役に立たない！すべてのコードの複雑さの測定値が役に立たないのと同じ理由で役に立たない：それらは失敗し、測定されたコードの複雑度（何であろうと）とコードが解決する問題。 常にプログラミング問題の途方もなく複雑な解決策を見つけて、LOCカウントを雇用者に印象付けることができますが、コードの複雑さの測定では、タスクが可能であることがわかりませんほんの少しの努力で解決されました。