Kann das Konzept der Entropie verwendet werden, um den Quellcode auf nützliche Weise zu analysieren?

Es scheint mir logisch, dass man einen Kontext für die statische Quellcode-Analyse definieren könnte, der Regeln enthält, um einen relativen Wert für die Komplexität zu erzeugen. Ich weiß, dass dies nicht im physischen Sinne der Fall ist, da der Quellcode nicht über "Energie" verfügt, aber ich wette, es wurden zumindest akademische Anstrengungen unternommen, um eine Parallele zu ziehen. Hat jemand Kenntnis davon und wenn ja, zu welchem ​​Zweck hat es nützliche Ergebnisse erbracht?

Es gibt bereits eine Reihe von Maßeinheiten für die Codekomplexität:

• Zyklomatische Komplexität
• Klassenlänge
• Methodenlänge
• Anzahl der Felder
• Anzahl der Methodenparameter
• N-Pfad Komplexität
• Fan-In und Fan-Out
• Datenflussanalyse (DU / DD-Ketten)

Es wurde daran gearbeitet, diese mit der Fehlerdichte, dem Wartungsaufwand und der Verständlichkeit in Beziehung zu setzen. Einige sind aussagekräftiger als andere, je nachdem, was Sie aus Ihrer Analyse lernen möchten. Ich bin mit dem Konzept der Entropie aus den physikalischen Wissenschaften nicht so vertraut, aber ich frage mich, ob das Verfolgen von Messungen und Metriken, wie ich sie über die Zeit benannt habe, und das Verknüpfen dieser mit Defekten über die Zeit dem entsprechen würde, wonach Sie suchen.

Sie könnten auch an Ivar Jacobsons Definition von Software-Entropie und Software-Rot interessiert sein . Die allgemeine Idee dieser Themen ist, dass sich das Softwaresystem im Laufe der Zeit verschlechtert, wenn sich der Code sowie die Ausführungsumgebung ändern. Refactoring wird als eine Methode zur Minimierung von Entropie oder Fäulnis angesehen, und zumindest nach meinen Erfahrungen wären die oben genannten Metriken und Messungen Indikatoren dafür, dass Refactoring in einem System oder Subsystem erforderlich sein könnte.

Ich denke, Sie versuchen, eine Parallele zwischen thermodynamischer Entropie und "Komplexität" zu ziehen. Die Sache ist, die Entropie ist ein Maß für die Störung, nicht für die Komplexität . Ich glaube nicht, dass die beiden gleichwertig und austauschbar sind.

Das der thermodynamischen Entropie am nächsten kommende Analogon ist die Shannon-Entropie, die das Ausmaß der Störung in einer Zufallsvariablen misst. Dieser Begriff befasst sich hauptsächlich mit der Menge an "Informationen" in einer Nachricht.

In dieser Hinsicht kann ein Codeteil eine Menge Informationen (hohe Entropie), aber eine sehr geringe Komplexität aufweisen. Stellen Sie sich ein Programm vor, das einfach eine sehr lange Folge beliebiger Zeichen ausgibt. Es hat viele Informationen, aber eine geringe Komplexität.

Die Entropie ist ein "Maß für die Unvorhersehbarkeit von Störungen". Ein größerer Bereich von eindeutigen Mustern in der Information (dh ungefähr "mehr Bedeutung") zeigt einen höheren Entropiegrad an.

Bezogen auf Computer-Quellcode denke ich, dass dieses Prinzip nützlich sein könnte. Es wäre jedoch erforderlich, ein Wahrscheinlichkeitsmodell für den Quellcode zu entwerfen, mit dem die Entropie berechnet werden kann. (Eine Datenstruktur, die leicht in den Sinn kommt, ist ein Diagramm mit verschiedenen Kantentypen: Aufruf, Klassenvererbung usw.)

Sobald das Modell entworfen und dann mit dem Quellcode einer Softwareanwendung (dh Frequenzen für Knoten / Kanten) gefüllt wurde, konnte die Entropie berechnet werden.

Ich kenne hierzu keine Forschungsergebnisse, aber meiner Intuition nach würde ein niedriger Entropiegrad bedeuten, dass der Quellcode in der gesamten Anwendung gemeinsame Muster wiederverwendet (z. B. DRY ). Umgekehrt würde ein hohes Maß an Entropie bedeuten, dass der Quellcode eine hohe Komplexität aufweist und nicht gut berücksichtigt wurde.

Eine Möglichkeit, über Entropie nachzudenken, besteht darin, "durchschnittliche Informationen zu gewinnen". Ich halte es daher für besser, auf die Modellierungsinformationen zurückzukommen. Ich kenne zwei grundlegende Ansätze zur mathematischen Modellierung von Informationen. (Verzeih mir, dass ich Wikipedia-Referenzen gebe, aber meiner Meinung nach sind sie nicht schlecht.)

• Shannon-Informationen , die Symbolsätze, Wahrscheinlichkeitsverteilungen auf diesen, Codes, die Informationen zwischen Symbolsätzen übertragen können, und Längen dieser Codes untersuchen. Die allgemeinen Konzepte der Codeeffizienz, des Rauschens, der Fehlererkennung und -korrektur über Redundanz usw. sind im Sinne der Shannon-Informationstheorie zusammengefasst. Eine Möglichkeit, Informationen auszudrücken, besteht darin, zu sagen, dass es sich um die Länge des kürzesten Binärcodes handelt, der ein Symbol darstellen kann. Dies basiert auf der Wahrscheinlichkeit, bei der es sich um einen numerischen Wert handelt, der einem Symbol oder Ereignis von einem Beobachter zugewiesen wurde.

• Solomonoff (oder Kolmogorov ) Informationen. Hier ist eine andere Erklärung. In dieser Formulierung wird der Informationsgehalt eines Symbols oder Ereignisses durch die Länge des kürzesten Programms dargestellt, das es berechnen könnte. Auch hier ist es relativ, nicht zu einem Beobachter, der die Wahrscheinlichkeit zuweist, sondern zu einer universellen Maschine, die das Programm ausführen kann. Da jede Universalmaschine von einer Universal-Turing-Maschine simuliert werden kann, bedeutet dies in gewisser Weise, dass der Informationsgehalt des Symbols oder Ereignisses nicht relativ, sondern absolut ist.

Wenn ich mir die Freiheit erlauben kann, zu sagen, was ich denke, bedeutet dies in alltäglichen Begriffen, über die ich ein Buch geschrieben habe , bedeutet dies einfach, dass die Komplexität eines Programms seine Länge ist, wenn Dinge wie die funktionale Spezifikation und Sprache angemessen konstant gehalten werden Zulagen für Dinge wie Kommentare und Namenslängen. Aber da gibt es ein Problem - das "APL-Tarpit", bei dem Prägnanz und Unverständlichkeit gleichkommen.

Es ist viel besser zu bedenken (wie ich es während des AI-Studiums getan habe), dass die Funktionsspezifikation des Programms aus einem mentalen Modell besteht, das nicht nur real, sondern auch effizient codiert ist, das heißt, mit einer ausreichend geringen Redundanz, die die eigene Meinung über die Anforderungen ändert kann durchgeführt werden, ohne die Gefahr zu groß zu machen, dass es intern inkonsistent wird - dh einen "Bug" aufweist. Dann ist der Programmierprozess ein Informationskanal, der das mentale Modell als Eingabe verwendet und dessen Ausgabe der funktionierende Quellcode ist. Wenn dann eine Änderung im mentalen Modell vorgenommen wird, muss dieses Delta durch den Programmierprozess geleitet und im Quellcode in ein entsprechendes Delta umgewandelt werden. Dieses Delta ist leicht zu messen. Unterscheiden Sie die Quelle zwischen vor dem Anwenden dieses Deltas und nach dem Anwenden (vollständig, mit allen ausgearbeiteten Fehlern). und zählen Sie die Anzahl der eingefügten, gelöschten und ersetzten Codeblöcke. Je kleiner das ist, desto besser repräsentiert die Quellcodesprache die Sprache, in der das mentale Modell dargestellt wird (in Bezug auf Substantive, Verben und Struktur). Wenn dieses Maß irgendwie über den Raum wahrscheinlicher funktionaler Änderungen gemittelt wird, ist dies ein Konzept der Entropie der Ausgangssprache, und weniger ist besser. Es gibt einen Begriff dafür -Domänenspezifische Sprache (DSL)

Es tut mir leid, wenn die Referenzen schwach / persönlich sind, aber ich halte diese allgemeine Frage für sehr wichtig.

Jon Jagger und Olve Maudal haben eine etwas andere Sicht auf Code Entropy, wie in ihrer Accu-Konferenzsitzung Code Entropy and Physics of Software von 2011 zu sehen ist .

Sie sprechen über die Stabilität des Codes in Bezug darauf, ob zukünftige Entwickler / Betreuer diesen Code wahrscheinlich ändern werden.

Um dies zu demonstrieren, führten sie eine Umfrage mit einer Reihe von Codefragmenten durch und die Ergebnisse waren sehr interessant.

• Es schien eine starke Voreingenommenheit gegenüber dem One-True-Brace-Stil zu geben .
• Aber eine starke Neigung , einzelne Aussagen zu akzeptieren , wenn's.
• Es gab starke Vorurteile gegen die Verwendung temporärer Variablen.
• Es gab eine starke Tendenz, Klammern hinzuzufügen, um die Priorität des Operators deutlich zu machen.

plus 16 andere.

Der allgemeine Trend schien darin zu bestehen, Code verständlicher und schwieriger zu verstehen.

Sie betrachten auch einige der Änderungen, die im Laufe der Jahre an einer großen Codebasis vorgenommen wurden.

Obwohl die Dias für sich genommen kein Protokoll der Sitzung sind, gibt es immer noch einige interessante Punkte.

Ich studierte bei einem Professor , der Entropie als Maß für die Komplexität von Programmen verwendete (unser Lehrbuch war eine ältere Ausgabe dieses Buches , einige seiner Pubs sind hier ). Es gab eine Reihe von Dissertationen an der FAU, bei denen dies eine der wichtigsten Maßnahmen war, aber die Website der Schule hat sich seit meinem letzten Besuch geändert, und ich kann nicht feststellen, wo sich die studentischen Arbeiten / Dissertationen jetzt befinden.

Eine solche Dissertation ist Informationstheorie und Softwaremessung .

Wenn Sie eine Definition wünschen, die "mathematisch" ist, wie die Entropie ist, sollten Sie sich die Kolmogorov-Komplexität ansehen, bei der die Komplexität an der minimalen Codemenge gemessen wird, in der möglicherweise etwas ausgeführt werden kann. Dies ist jedoch keine Codekomplexität. aber von dem, was Sie versuchen, mit dem Code zu tun. Vielleicht halten Sie es jedoch für relevant, da Sie theoretisch einen bestimmten Code mit dem minimalen Code vergleichen können. Dies ist jedoch gegenwärtig keine nützliche Technik zum Messen der Komplexität von Code aus der realen Welt.

Ich halte dies für nicht durchführbar, man könnte argumentieren, dass eine gut geschriebene Codebasis eine höhere Entropie (Störung) haben sollte. Denken Sie an eine Codebasis, in der Code-Snippet immer wieder wiederholt wird. Sie kann aufgrund von sich wiederholenden Teilen (geringere Entropie / Dateigröße) mit hoher Komprimierungsrate komprimiert werden. Wenn Sie den Code jedoch in eine separate Funktion verschieben, ist die Komprimierungsrate geringer (höhere Entropie / Dateigröße).

Man kann sich also denken, ich kann so etwas wie Entropy / CodeLines unter Verwendung des Kompressionsverhältnisses als Koeffizienten berechnen, um die Codequalität zu messen. Dies hat jedoch das Problem, dass die gesamte Zufallseingabe wie der beste Code der Welt aussehen würde, was offensichtlich nicht der Fall ist.

In der Tat ist das Kompressionsverhältnis ein gutes Messgerät zum Messen der Code-Entropie, jedoch sind beide kein gutes Messgerät für die Code-Qualität.

Nun, der Begriff Entropie taucht nicht nur in der Thermodynamik und Informationstheorie auf, sondern auch in der realen Welt der Datenkomprimierung. In diesem Zusammenhang ist die Entropie, die der Kompressor sieht, gleich der Anzahl von Bits, die er erzeugt. (Beachten Sie, dass ich "die Entropie, die der Kompressor sieht " sagte , denn was als Entropie gilt, hängt von dem Modell ab, das der Kompressor zur Beschreibung der Eingabedaten verwendet. Dies ist der Grund, warum verschiedene Kompressoren Dateien unterschiedlicher Größe erzeugen: Was ist Entropie für den Kompressor? Eine Struktur ist für die andere ausnutzbar.)

Dies lässt sich prinzipiell wunderbar auf die Komplexität des Quellcodes anwenden: Schreiben Sie einfach einen Kompressor, der nur mit vollständig standardkonformem Quellcode funktioniert und der ihn komprimiert und wie ein Compiler analysiert, um den entsprechenden Syntaxbaum zu erstellen. Dann kann er diesen Syntaxbaum durchgehen und an jedem Knoten entscheiden, welche Knoten an jedem Punkt möglich gewesen wären, und diesen Knoten mit diesem Wissen codieren.

Wenn die Sprache beispielsweise einen vorhandenen Bezeichner oder einen in Klammern gesetzten Bezeichner oder ein Produkt an einer bestimmten Stelle zulässt, zählt der Kompressor die möglichen vorhandenen Bezeichner unter Berücksichtigung der Typinformationen (z. B. 3 solcher Bezeichner) ) und addiere 2 für die zwei möglichen Unterausdrücke, was 5 Möglichkeiten ergibt. Der Knoten würde also mit lb 5 = 2.32Bits codiert . Im Fall der zwei möglichen Unterausdrücke würden mehr Bits benötigt, um ihren Inhalt zu codieren.

Dies würde in der Tat ein sehr genaues Maß für die Komplexität des Codes sein. Diese Maßnahme ist jedoch immer noch unbrauchbar! Es ist aus dem gleichen Grund nutzlos, dass alle Messungen der Codekomplexität nutzlos sind: Sie schlagen fehl, um die Verbindung zwischen der gemessenen Codekomplexität (wie auch immer) und der Komplexität des Problems, das der Code löst, herzustellen. Sie können immer lächerlich komplexe Lösungen für Ihre Programmierprobleme finden, um Ihren Arbeitgeber mit Ihren LOC-Zahlen zu beeindrucken, aber kein Maß für die Codekomplexität sagt Ihnen, dass die Aufgabe mit einem Bruchteil des Aufwands hätte gelöst werden können.

Code hat genau so viel Entropie wie die Zahl π.

Die Pflege und Änderung des Codes kann zu Entropie führen (da es sich möglicherweise um eine Zustandsänderung handelt).

Code ist jedoch nur eine große Zahl. Mit einer binären Darstellung.