エントロピーの概念を使用して、ソースコードを便利な方法で分析できますか？

複雑さの相対的な価値を生み出すルールを含む静的ソースコード分析のコンテキストを定義できると私には思えます。ソースコードには「エネルギー」がないため、物理的な意味ではそうではないことはわかっていますが、少なくとも学問的には類似性を引き出す努力が行われていると確信しています。これについての知識はありますか？

コードの複雑さの尺度はすでにいくつかあります。

• 循環的な複雑さ
• クラスの長さ
• メソッドの長さ
• フィールド数
• メソッドパラメータの数
• Nパスの複雑さ
• ファンインおよびファンアウト
• データフロー分析（DU / DDチェーン）

これらを欠陥密度、維持の努力、および理解の容易さに関連付ける作業が行われました。分析から何を学ぼうとしているかに応じて、いくつかは他のものよりも有意義です。私は物理科学のエントロピーの概念にそれほど詳しくありませんが、時間の経過とともに名前を付けたような測定値と測定値を追跡し、それらを時間の経過に伴う欠陥に関連付けることは、あなたが探しているものと似ているでしょうか？

Ivar Jacobsonのソフトウェアエントロピーとソフトウェアrot の定義にも興味があるかもしれません。これらのトピックの一般的な考え方は、コードと実行環境が変化するにつれて、ソフトウェアシステムが劣化し始めるということです。リファクタリングはエントロピーまたは腐敗を最小限に抑える方法と見なされます。少なくとも私の経験では、上記のメトリックと測定値は、システムまたはサブシステムでリファクタリングが必要になる可能性があることを示す指標になります。

熱力学的なエントロピーと「複雑さ」の間に類似点を引き出そうとしていると思います。事は、エントロピーは複雑さではなく無秩序の尺度です。この2つが同等で互換性があるとは思いません。

熱力学的エントロピーに最も近いのは、ランダム変数の乱れの量を測定するシャノンエントロピーです。この概念は、主にメッセージ内の「情報」の量に関係しています。

その点で、コードの一部は多くの情報（高いエントロピー）を持つことができますが、複雑さは非常に低くなります。任意の文字の非常に長い文字列を単に出力するプログラムを考えてください。多くの情報がありますが、複雑さは低いです。

エントロピーは、「障害[または]予測不能性の尺度」です。情報内のより広い範囲の一意のパターン（つまり、おおよそ「より多くの意味」）は、エントロピーの度合いが高いことを示します。

コンピューターのソースコードに適用すると、この原則が役立つと思います。ただし、エントロピーの計算に使用するソースコードの確率モデルを設計する必要があります。（すぐに思い浮かぶデータ構造は、呼び出し、クラス継承など、さまざまなエッジタイプを持つグラフです。）

モデルを設計し、ソフトウェアアプリケーションのソースコード（ノード/エッジの周波数）を入力すると、エントロピーを計算できます。

私はこれに関する研究を知りませんが、私の直感では、エントロピーの程度が低いと、ソースコードはアプリケーション全体で共通のパターンを再利用します（つまり、DRY）。逆に、エントロピーの度合いが高いということは、ソースコードの複雑さが高く、適切にファクタリングされていないことを意味します。

エントロピーを考える1つの方法は「得られる平均的な情報」なので、モデリング情報に戻ったほうが良いと思います。情報を数学的にモデリングするための2つの基本的なアプローチを知っています。（ウィキペディアの参考文献を提供してくれたのはお許しください。しかし、私見では悪くありません。）

• Shannon Informationは、シンボルセット、それらの確率分布、シンボルセット間で情報を転送できるコード、およびそれらのコードの長さを調べます。コード効率、ノイズ、冗長性によるエラー検出および訂正などの一般的な概念は、シャノン情報理論の観点から説明されています。情報を表現する1つの方法は、シンボルを表すことができる最短のバイナリコードの長さと言うことです。これは確率に基づいています。確率は、観測者によってシンボルまたはイベントに割り当てられた数値です。

• ソロモノフ（またはコルモゴロフ）情報。別の説明があります。この定式化では、シンボルまたはイベントの情報内容は、それを計算できる最短のプログラムの長さで表されます。ここでも、オブザーバーが確率を割り当てるのではなく、プログラムを実行できるユニバーサルマシンに関連しています。すべてのユニバーサルマシンはユニバーサルチューリングマシンによってシミュレートできるため、ある意味で、シンボルまたはイベントの情報コンテンツは相対的ではなく、絶対的であることを意味します。

私がこれを意味していると思うことを私が本を書いたという意味で言う自由をとることができるなら、それは単にプログラムの複雑さがその長さであることを意味し、機能仕様や言語のようなものが適切に保持されているときコメントや名前の長さなどの許可。しかし、これには問題があります-「APL tarpit」。簡潔さは理解しにくいことです。

プログラムの機能仕様は、本物であるだけでなく、効率的にエンコードされた精神モデルで構成されていること、つまり要件について気が変わるほど小さい冗長性を備えていることを検討する方がはるかに良いです（AIの研究中に行ったように）内部的に矛盾を生じさせる危険があまりない状態で実行できます。つまり、「バグ」が発生します。プログラミングのプロセスは、メンタルモデルを入力として受け取る情報チャネルであり、その出力は作業ソースコードです。次に、メンタルモデルに変更が加えられた場合、そのデルタをプログラミングプロセスに送り、ソースコード内の対応するデルタに変換する必要があります。そのデルタは簡単に測定できます。そのデルタを適用する前と適用した後（完全に、すべてのバグが解決した）でソースを比較します。挿入、削除、および置換されたコードブロックの数をカウントします。小さいほど、ソースコード言語は、精神モデルが表現されている言語（名詞、動詞、および構造の観点から）をより適切に表します。その測定値が何らかの形で機能的変化の可能性のある空間で平均化されている場合、それはソース言語のエントロピーの概念であり、少ない方が優れています。これには用語があります-ドメイン固有言語（DSL）

参照が弱い/個人的な場合は申し訳ありませんが、この全体的な質問は非常に重要なものだと思います。

Jon JaggerとOlve Maudalは、2011年のAccu会議セッションCode Entropy and Physics of Softwareで見られるように、Code Entropyの見方が少し異なります。

彼らは、将来の開発者/保守者がそのコードを変更する可能性があるかどうかに関連するコードの安定性について話します。

これを実証するために、彼らは多くのコードスニペットで調査を実施しましたが、結果は非常に興味深いものでした。

• one-true-braceスタイルに対して強いバイアスがあるように見えました。
• しかし、もし単一のステートメントを受け入れるなら、それは強いバイアスです。
• 一時変数の使用に対して強いバイアスがありました。
• 演算子の優先順位を明確にするために、括弧を追加することには強いバイアスがありました。

さらに16人。

一般的な傾向は、コードを理解しやすくし、誤解しにくくすることであるように思われました。

彼らはまた、長年にわたって大規模なコードベースに加えられた変更のいくつかにも注目しています。

スライド自体はセッションのトランスクリプトではないことに苦しんでいますが、まだ興味深い点がいくつかあります。

私は、プログラムの複雑さの尺度としてエントロピーを使用した教授の下で勉強しました（私たちの教科書はこの本の古い版で、彼のパブのいくつかはここにあります）。FAUには多数の学位論文がありましたが、これは主要な対策の1つでしたが、学校のウェブサイトは前回見て以来変更されており、学生論文/学位論文の場所を特定できません。

そのような論文の1つは、情報理論とソフトウェア測定です。

エントロピーのように「数学的な」定義が必要な場合は、コルモゴロフの複雑さを調べてください。これは、可能な限り最小のコード量で複雑さを測定します。ただし、これはコードの複雑さではありません。しかし、あなたがコードで何をしようとしているのか。しかし、理論的には特定のコードを最小限のコードと比較できるため、これは関連性があると考えるかもしれません。ただし、これは現在、実世界のコードの複雑さを測定するための有用な手法ではありません。

これは実行可能ではないと思います。適切に記述されたコードベースには、より高いエントロピー（障害）が必要であると主張できます。コードスニペットが何度も繰り返されるコードベースを考えてください。繰り返し部分（低エントロピー/ファイルサイズ）のために高い圧縮率で圧縮できますが、コードを別の関数に移動すると圧縮率が低くなります（より高いエントロピー/ファイルサイズ）。

だから、圧縮率を係数として使用してエントロピー/コードラインのようなものを計算してコード品質を測定することができますが、これには、ランダム入力全体が世界で最高のコードではないように見えるという問題があります。

実際、圧縮率はコードのエントロピーを測定するのに適したメーターですが、両方ともコードの品質に適したメーターではありません。

エントロピーという用語は、熱力学と情報理論にだけでなく、データ圧縮の現実の世界にも現れます。そのコンテキストでは、コンプレッサーが見るエントロピーは、生成するビット数に等しくなります。（エントロピーと見なされるものは、コンプレッサーが入力データを記述するために使用するモデルに依存するため、「コンプレッサーが見るエントロピー」と述べたことに注意してください。これは、異なるコンプレッサーが異なるサイズのファイルを生成する理由です：一方は他方に対して悪用可能な構造です。）

これは、原則として、ソースコードの複雑さに美しく適用できます。完全に標準に準拠したソースコードでのみ動作し、実際にそれを圧縮してコンパイラーのように解析し、対応する構文ツリーを生成するコンプレッサーを記述するだけです。次に、この構文ツリーをたどって、各ノードでどのノードが可能になるかを各ノードで決定し、そのノードをその知識でエンコードできます。

したがって、たとえば、言語が既存の識別子、または括弧で囲まれた何か、または特定の時点での製品のいずれかを許可する場合、コンプレッサーはタイプ情報を考慮して、可能な既存の識別子をカウントします）、2つの可能な部分式に2を追加して、5つの可能性を与えます。したがって、ノードはlb 5 = 2.32ビットでエンコードされます。2つの可能な部分式の場合、コンテンツをエンコードするにはより多くのビットが必要になります。

これにより、実際のコードの複雑さを非常に正確に測定できます。ただし、この方法はまだ役に立ちません！すべてのコードの複雑さの測定が役に立たないのと同じ理由で役に立たない：測定されたコードの複雑さ（それが何であれ）とコードが解決する問題の複雑さの間の接続を引き出せない。あなたは、することができます常にあなたのLOCカウントであなたの雇用者を感動させるあなたのプログラミングの問題に途方もなく複雑なソリューションを見つけることが、ないコードの複雑さの尺度は、タスクは努力の一部で解決されている可能性があることを教えてくれません。

コードのエントロピーは、数πとまったく同じです。

コードの保守と変更によりエントロピーが導入される場合があります（状態の変更が関係する可能性があるため）。

しかし、コードは大きな数字です。バイナリ表現で。