Mi sembra logico che si possa definire un contesto per l'analisi statica del codice sorgente che includesse le regole per produrre un valore relativo di complessità. So che non è come in senso fisico perché il codice di salsa non ha "Energia", ma scommetto che ci sono stati sforzi, almeno a livello accademico, per disegnare un parallelo. Qualcuno ha qualche conoscenza di questo e se sì, a quale scopo ha prodotto risultati utili?
Esistono già numerose misure di complessità del codice:
È stato fatto del lavoro per correlare questi fattori alla densità dei difetti, allo sforzo di manutenzione 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 le misurazioni e le metriche di tracciamento come quelle che ho nominato nel corso del tempo e che li colleghino ai difetti nel tempo, sarebbero simili a ciò che state cercando.
Potresti anche essere interessato a la definizione di Ivar Jacobson di entropia del software e software rot . 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 degradarsi. 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 di disturbo non complessità . Non credo che i due siano equivalenti e intercambiabili.
L'entropia più simile a quella termodinamica è 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 riguardo, un pezzo di codice può avere molte informazioni (alta entropia) ma una complessità molto bassa. Pensa a un programma che stampa semplicemente una stringa molto lunga di caratteri arbitrari. Ha molte informazioni, ma una bassa complessità.
Entropia è una "misura di disordine [o] imprevedibilità". Una gamma più ampia di modelli unici nell'informazione (vale a dire "più significato") indicano un grado più elevato di entropia.
Applicato al codice sorgente del computer, penso che questo principio potrebbe essere utile. Tuttavia, sarebbe necessario progettare un modello probabilistico per il codice sorgente con cui calcolare l'entropia. (Una struttura dati che viene subito in mente è un grafico con diversi tipi di bordo: chiamata, ereditarietà di classe, ecc.)
Una volta che il modello è stato progettato e poi popolato con il codice sorgente di un'applicazione software (cioè frequenze per nodi / spigoli), l'entropia potrebbe essere calcolata.
Non so di 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 (cioè DRY ). Viceversa, un alto grado di entropia significherebbe che il codice sorgente ha una complessità elevata e non è stato preso bene in considerazione.
Un modo per 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 fornito riferimenti a Wikipedia, ma IMHO non sono male.)
Informazioni Shannon , che esaminano i set di simboli, le distribuzioni di probabilità su quelli, i codici che possono trasferire le informazioni tra set di simboli e lunghezze di tali codici. I concetti generali di efficienza del codice, rumore, rilevamento e correzione degli errori tramite ridondanza, ecc., Sono formulati 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 è basato sulla probabilità, che è un valore numerico assegnato ad un simbolo o evento da qualche osservatore.
Solomonoff (o Kolmogorov ) informazioni. Ecco un'altra spiegazione. In questa formulazione, il contenuto informativo di un simbolo o di un evento è rappresentato dalla lunghezza del più breve programma che potrebbe calcolarlo. Anche qui, è relativo, non a un osservatore che assegna la 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 permettermi di dire quello che penso significhi in termini quotidiani, su quale 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à appropriate per cose come commenti e lunghezze dei nomi. Ma c'è un problema con questo - il "tarpit APL", dove la concisione equivale all'incomprensibilità.
È molto meglio considerare (come ho fatto mentre studiavo l'intelligenza artificiale) che le specifiche funzionali del programma consistono in un modello mentale, che non è solo reale, ma codificato in modo efficiente, cioè con una ridondanza abbastanza piccola che cambia la propria mente sui requisiti può essere fatto senza troppo pericolo di renderlo internamente incoerente - cioè con un "bug". Quindi il processo di programmazione è un canale di informazione che prende come input il modello mentale e il suo output è il codice sorgente funzionante. Quindi, quando viene apportato un cambiamento 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. Diff tra la sorgente prima di applicare quel delta e dopo averlo applicato (completamente, con tutti gli errori risolti), e contare il numero di blocchi di codice inseriti, cancellati e sostituiti. Più piccolo è, migliore è il linguaggio del codice sorgente che rappresenta la lingua in cui è rappresentato il modello mentale (in termini di nomi, verbi e struttura). Se quella misura è in qualche modo mediata sullo 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 ha una visione leggermente diversa del Code Entropy, come si può vedere nella sessione della conferenza Accu 2011 Entropia del codice e fisica del software .
Parlano della stabilità del codice correlata al fatto che i futuri sviluppatori / manutentori possano modificare tale codice.
Per dimostrarlo, hanno eseguito un sondaggio con una serie di frammenti di codice e i risultati sono stati piuttosto interessanti.
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.
Anche se le diapositive da sole non sono una trascrizione della sessione, ci sono comunque alcuni punti interessanti.
Ho studiato con un professore che usava l'entropia come misura della complessità dei programmi (il nostro libro di testo era un precedente edizione di questa , alcuni dei suoi pub sono here ). C'era una serie di dissertazioni alla FAU dove questa era una delle principali misure, ma il sito web della scuola è cambiato dall'ultima volta che ho visto, e non sono in grado di individuare dove si trovano ora le tesi di laurea / dissertazioni.
Una di queste tesi è Teoria delle informazioni e misurazione del software .
Se si desidera una definizione che sia "matica" nel modo in cui l'entropia è, si potrebbe voler considerare la complessità di Kolmogorov, che misura la complessità con la quantità minima di codice in cui qualcosa potrebbe essere fatto. Tuttavia, questa non è complessità di codice, ma di quello che stai cercando di fare con il codice. Ma potresti pensare che sia rilevante 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 fattibile, si potrebbe sostenere che una base di codice ben scritta dovrebbe avere un'entropia più alta (disturbo). Pensa a una base di codice in cui lo snippet di codice viene ripetuto più volte, può essere compresso con un rapporto di compressione elevato a causa della ripetizione della parte (entropia / dimensioni del file), tuttavia se si sposta il codice su una funzione separata il rapporto di compressione sarà inferiore (maggiore entropia / dimensione del file).
Quindi si può pensare, quindi posso calcolare qualcosa come Entropy / CodeLines usando il coefficiente di compressione come coefficiente, per misurare la qualità del codice, tuttavia questo ha il problema che l'input casuale totale assomiglierebbe al miglior codice del mondo che è ovviamente no.
In effetti il rapporto di compressione è un buon metro per misurare l'entropia del codice, tuttavia entrambi non sono buoni contatori 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 il compressore vede ", 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 differenti dimensione: ciò che è l'entropia di uno è struttura sfruttabile verso l'altro.)
Questo può, in linea di principio, essere magnificamente applicato alla complessità del codice sorgente: "Basta" scrivere un compressore che funziona solo su un codice sorgente pienamente conforme e che lo comprime effettivamente analizzandolo come 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 sia 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 (ad esempio, hai 3 identificatori di questo tipo) e aggiungi 2 per le due possibili sottoespressioni, dando 5 possibilità. Quindi il nodo verrebbe codificato con lb 5 = 2.32 bit. Nel caso delle due possibili sottoespressioni, sarebbero necessari più bit per codificare il loro contenuto.
Ciò fornirebbe una misura molto accurata per la complessità del codice così com'è. Tuttavia, questa misura è ancora inutile! È inutile per la stessa ragione per cui tutte le misurazioni della complessità del codice sono inutili: falliscono disegnare 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 stupire il tuo datore di lavoro con i tuoi conteggi LOC, ma nessuna misura di complessità del codice ti dirà che il compito avrebbe potuto essere risolto con una frazione dello sforzo.
Il codice ha esattamente l'entropia del numero π.
La manutenzione e il cambiamento del codice possono introdurre entropia (perché c'è un possibile cambio di stato coinvolto).
Ma il codice è solo un grande numero. Con una rappresentazione binaria.
Leggi altre domande sui tag code-quality static-analysis