Il concetto di Entropy può essere utilizzato per analizzare il codice sorgente in modo utile?

Mi sembra logico che si possa definire un contesto per l'analisi del codice sorgente statico che includa regole per produrre un valore relativo della complessità. So che non è come in senso fisico perché il codice Souce non ha "Energia", ma sto scommettendo che ci sono stati degli sforzi, almeno accademici, per tracciare un parallelo. Qualcuno ne è a conoscenza e, in tal caso, a che scopo ha prodotto risultati utili?

Esistono già alcune misure di complessità del codice:

• Complessità ciclomatica
• Durata della lezione
• Lunghezza del metodo
• Numero di campi
• Numero di parametri del metodo
• Complessità del percorso N
• Fan-in e fan-out
• Analisi del flusso di dati (catene DU / DD)

È stato fatto un lavoro per correlarli alla densità dei difetti, allo sforzo di mantenere e alla facilità di comprensione. Alcuni sono più significativi di altri, a seconda di ciò che stai cercando di imparare dalla tua analisi. Non ho familiarità con il concetto di entropia delle scienze fisiche, ma mi chiedo se rintracciare misurazioni e metriche come quelle che ho nominato nel tempo e metterle in relazione con difetti nel tempo, sarebbe simile a quello che stai cercando.

Potresti anche essere interessato alla definizione di Ivar Jacobson di entropia del software e marciume del software . L'idea generale di questi argomenti è che nel tempo, man mano che il codice e l'ambiente di esecuzione cambiano, il sistema software inizia a degradare. Il refactoring è visto come un metodo per ridurre al minimo l'entropia o il marciume e, almeno nelle mie esperienze, le metriche e le misure che ho menzionato sopra sarebbero indicatori che il refactoring potrebbe essere necessario in un sistema o sottosistema.

Penso che tu stia cercando di tracciare un parallelo tra entropia termodinamica e "complessità". Il fatto è che l'entropia è una misura del disordine e non della complessità . Non credo che i due siano equivalenti e intercambiabili.

L'analogo più vicino all'entropia termodinamica è l'entropia di Shannon che misura la quantità di disturbo in una variabile casuale. Questa nozione riguarda principalmente la quantità di "informazioni" in un messaggio.

A tale proposito, un pezzo di codice può contenere molte informazioni (elevata entropia) ma una complessità molto bassa. Pensa a un programma che stampa semplicemente una lunghissima serie di caratteri arbitrari. Ha molte informazioni, ma bassa complessità.

L'entropia è una "misura del disordine [o] dell'imprevedibilità". Una più ampia gamma di modelli unici nelle informazioni (cioè approssimativamente "più significato") indica un grado più elevato di entropia.

Applicato al codice sorgente del computer, penso che questo principio possa essere utile. Tuttavia, sarebbe necessario progettare un modello probabilistico per il codice sorgente con cui calcolare l'entropia. (Una struttura di dati che viene subito in mente è un grafico con diversi tipi di bordi: chiamata, eredità di classe, ecc.)

Una volta che il modello è stato progettato e popolato con il codice sorgente di un'applicazione software (ovvero frequenze per nodi / bordi), è possibile calcolare l'entropia.

Non conosco alcuna ricerca su questo, ma la mia intuizione è che un basso grado di entropia significherebbe che il codice sorgente riutilizza schemi comuni in tutta l'applicazione (ad esempio DRY ). Al contrario, un alto grado di entropia significherebbe che il codice sorgente è molto complesso e non è stato considerato bene.

Un modo di pensare all'entropia è "l'informazione media da acquisire", quindi penso che sia meglio tornare alle informazioni sulla modellazione. Conosco due approcci di base per modellare matematicamente le informazioni. (Perdonami per aver dato riferimenti a Wikipedia, ma IMHO non sono male.)

• Shannon Information , che esamina le serie di simboli, le distribuzioni di probabilità su quelle, i codici che possono trasferire informazioni tra le serie di simboli e le lunghezze di tali codici. I concetti generali di efficienza del codice, rumore, rilevamento degli errori e correzione tramite ridondanza, ecc. Sono definiti in termini di teoria dell'informazione di Shannon. Un modo per esprimere informazioni è dire che è la lunghezza del codice binario più corto che potrebbe rappresentare un simbolo. Questo si basa sulla probabilità, che è un valore numerico assegnato a un simbolo o evento da un osservatore.

• Informazioni su Solomonoff (o Kolmogorov ). Ecco un'altra spiegazione. In questa formulazione, il contenuto informativo di un simbolo o evento è rappresentato dalla lunghezza del programma più breve che potrebbe calcolarlo. Anche in questo caso, è relativo, non a un osservatore che assegna probabilità, ma a una macchina universale che può eseguire il programma. Poiché ogni macchina universale può essere simulata da una macchina di Turing universale, ciò significa, in un certo senso, che il contenuto informativo del simbolo o dell'evento non è relativo, ma assoluto.

Se posso prendermi la libertà di dire cosa penso che ciò significhi in termini quotidiani, di cui ho scritto un libro , significa semplicemente che la complessità di un programma è la sua lunghezza, quando cose come le specifiche funzionali e il linguaggio sono mantenuti costanti, con indennità per cose come commenti e lunghezza dei nomi. Ma c'è un problema con questo: il "tarpit APL", in cui la concisione equivale a incomprensibilità.

È molto meglio considerare (come ho fatto mentre studiavo AI) che le specifiche funzionali del programma sono costituite da un modello mentale, che non è solo reale, ma è codificato in modo efficiente, cioè con una ridondanza abbastanza piccola da cambiare idea sui requisiti può essere fatto senza troppi rischi di renderlo internamente incoerente, ovvero avere un "bug". Quindi il processo di programmazione è un canale informativo che accetta come input il modello mentale e il suo output è il codice sorgente funzionante. Quindi, quando viene effettuata una modifica nel modello mentale, quel delta deve essere alimentato attraverso il processo di programmazione e trasformato in un delta corrispondente nel codice sorgente. Quel delta è facilmente misurabile. Diffondi la fonte tra prima di applicare quel delta e dopo averlo applicato (completamente, con tutti i bug risolti), e contare il numero di blocchi di codice inseriti, eliminati e sostituiti. Più piccolo è, migliore è il linguaggio del codice sorgente che rappresenta il linguaggio in cui è rappresentato il modello mentale (in termini di nomi, verbi e struttura). Se tale misura è mediata in qualche modo nello spazio di probabili cambiamenti funzionali, questo è un concetto di entropia della lingua di partenza e meno è meglio. C'è un termine per questo -Domain Specific Language (DSL)

Mi dispiace se i riferimenti sono deboli / personali, ma penso che questa domanda generale sia molto importante.

Jon Jagger e Olve Maudal hanno una visione leggermente diversa di Code Entropy, come si può vedere nella sessione della conferenza Accu del 2011, Entropia del codice e fisica del software .

Parlano della stabilità del codice in relazione al fatto che i futuri sviluppatori / manutentori probabilmente cambieranno quel codice.

Per dimostrarlo, hanno eseguito un sondaggio con una serie di frammenti di codice e i risultati sono stati piuttosto interessanti.

• Sembrava esserci un forte pregiudizio contro lo stile di un tutore vero .
• Ma una forte propensione ad abbracciare una singola affermazione se è.
• Vi era una forte propensione all'utilizzo di variabili temporanee.
• C'era una forte propensione per l'aggiunta di parentesi per rendere ovvia la precedenza dell'operatore.

più altri 16.

La tendenza generale sembrava essere quella di rendere il codice più facile da comprendere e più difficile da comprendere male.

Esaminano anche alcune delle modifiche apportate a una base di codice di grandi dimensioni nel corso degli anni.

Sebbene le diapositive da sole soffrano di non essere una trascrizione della sessione, ci sono ancora alcuni punti interessanti.

Ho studiato con un professore che ha usato l'entropia come misura della complessità dei programmi (il nostro libro di testo era un'edizione precedente di questo , alcuni dei suoi pub sono qui ). Ci sono state una serie di tesi alla FAU in cui questa era una delle misure principali, ma il sito web della scuola è cambiato dall'ultima volta che ho guardato, e non sono in grado di individuare dove si trovano ora le tesi / tesi degli studenti.

Una di queste tesi è la teoria dell'informazione e la misurazione del software .

Se desideri una definizione che sia "mathy" come l'entropia, potresti voler esaminare la complessità di Kolmogorov, che misura la complessità in base alla quantità minima di codice in cui si potrebbe eventualmente fare qualcosa. Tuttavia, questa non è complessità del codice, ma di ciò che stai cercando di fare con il codice. Ma potresti pensare che sia pertinente perché potresti teoricamente confrontare un particolare pezzo di codice con quello minimo. Tuttavia, questa non è attualmente una tecnica utile per misurare la complessità del codice del mondo reale.

Penso che questo non sia praticabile, si potrebbe sostenere che una base di codice ben scritta dovrebbe avere una maggiore entropia (disturbo). Pensa a una base di codice in cui lo snippet di codice viene ripetuto più e più volte, può essere compresso con un elevato rapporto di compressione a causa della parte ripetuta (entropia / dimensione del file inferiore), tuttavia se sposti il ​​codice in una funzione separata il rapporto di compressione sarà inferiore (maggiore entropia / dimensione del file).

Quindi si potrebbe pensare, quindi posso calcolare qualcosa come Entropy / CodeLines usando il rapporto di compressione come coefficiente, per misurare la qualità del codice, tuttavia questo ha il problema che l'input casuale totale sembrerebbe il miglior codice al mondo che ovviamente non lo è.

In effetti il ​​rapporto di compressione è un buon metro per misurare l'entropia del codice, tuttavia entrambi non sono buoni per la qualità del codice.

Bene, il termine entropia non appare solo nella termodinamica e nella teoria dell'informazione, ma appare anche nel mondo reale della compressione dei dati. In quel contesto, l'entropia che il compressore vede è uguale al numero di bit che produce. (Si noti che ho detto "l'entropia che vede il compressore ", perché ciò che è considerato entropia dipende dal modello utilizzato dal compressore per descrivere i dati di input. Questo è il motivo per cui diversi compressori producono file di dimensioni diverse: cos'è l'entropia per uno è struttura sfruttabile all'altro).

Questo può, in linea di principio, essere meravigliosamente applicato alla complessità del codice sorgente: "Just" scrive un compressore che funziona solo su un codice sorgente completamente standard e che lo comprime effettivamente analizzandolo come farebbe un compilatore, producendo l'albero di sintassi corrispondente. Quindi può camminare su questo albero di sintassi e decidere su ciascun nodo quali nodi sarebbero stati possibili in ogni punto, codificando quel nodo con quella conoscenza.

Quindi, ad esempio, se la lingua consente un identificatore esistente, o qualcosa racchiuso tra parentesi o un prodotto in un punto specifico, il compressore conterà i possibili identificatori esistenti, tenendo conto delle informazioni sul tipo (supponiamo che tu abbia 3 di tali identificatori ) e aggiungi 2 per le due possibili sottoespressioni, dando 5 possibilità. Quindi il nodo verrebbe codificato con lb 5 = 2.32bit. Nel caso delle due possibili sottoespressioni, sarebbero necessari più bit per codificare il loro contenuto.

Ciò darebbe davvero una misura molto accurata della complessità del codice così com'è. Tuttavia, questa misura è ancora inutile! È inutile per lo stesso motivo per cui tutte le misurazioni della complessità del codice sono inutili: falliscono nel tracciare la connessione tra la complessità del codice misurata (qualunque essa sia) e la complessità del problema che il codice risolve. Puoi sempre trovare soluzioni ridicolmente complesse ai tuoi problemi di programmazione per impressionare il tuo datore di lavoro con i tuoi conteggi LOC, ma nessuna misura di complessità del codice ti dirà che l'attività potrebbe essere stata risolta con una frazione dello sforzo.

Il codice ha esattamente la stessa entropia del numero π.

La manutenzione e la modifica del codice possono introdurre entropia (poiché è possibile che si verifichi un cambiamento di stato).

Ma il codice è solo un gran numero. Con una rappresentazione binaria.