Me parece lógico que uno pueda definir un contexto para el análisis de código fuente estático que incluye reglas para producir un valor relativo de complejidad. Sé que no es así en el sentido físico porque el código fuente no tiene "Energía", pero apuesto a que ha habido esfuerzos, al menos académicos, para establecer un paralelismo. ¿Alguien tiene conocimiento de esto y, de ser así, con qué fin ha producido resultados útiles?
code-quality
static-analysis
Aaron Anodide
fuente
fuente
Respuestas:
Ya hay una serie de medidas de complejidad del código:
Se ha trabajado para correlacionarlos con la densidad de defectos, el esfuerzo de mantenimiento y la facilidad de comprensión. Algunos son más significativos que otros, dependiendo de lo que intente aprender de su análisis. No estoy tan familiarizado con el concepto de entropía de las ciencias físicas, pero me pregunto si el seguimiento de mediciones y métricas como las que mencioné con el tiempo, y relacionarlas con defectos a lo largo del tiempo, sería similar a lo que está buscando.
Usted también podría estar interesado en la definición de Ivar Jacobson de entropía de software y podredumbre de software . La idea general de estos temas es que con el tiempo, a medida que cambia el código y el entorno de ejecución, el sistema de software comienza a degradarse. La refactorización se ve como un método para minimizar la entropía o la podredumbre, y, al menos en mi experiencia, las métricas y mediciones que mencioné anteriormente serían indicadores de que la refactorización podría ser necesaria en un sistema o subsistema.
fuente
Creo que estás tratando de trazar un paralelo entre la entropía termodinámica y la "complejidad". La cuestión es que la entropía es una medida del desorden, no de la complejidad . No creo que los dos sean equivalentes e intercambiables.
El análogo más cercano a la entropía termodinámica es la entropía de Shannon, que mide la cantidad de trastorno en una variable aleatoria. Esta noción se refiere principalmente a la cantidad de "información" en un mensaje.
En ese sentido, un código puede tener mucha información (alta entropía) pero muy baja complejidad. Piense en un programa que simplemente imprima una cadena muy larga de caracteres arbitrarios. Tiene mucha información, pero poca complejidad.
fuente
La entropía es una "medida de desorden [o] imprevisibilidad". Un rango más amplio de patrones únicos en la información (es decir, aproximadamente "más significado") indica un mayor grado de entropía.
Aplicado al código fuente de la computadora, creo que este principio podría ser útil. Sin embargo, sería necesario diseñar un modelo probabilístico para el código fuente con el cual calcular la entropía. (Una estructura de datos que viene fácilmente a la mente es un gráfico con diferentes tipos de borde: llamada, herencia de clase, etc.)
Una vez que el modelo se diseña y luego se rellena con el código fuente de una aplicación de software (es decir, frecuencias para nodos / bordes), se puede calcular la entropía.
No conozco ninguna investigación sobre esto, pero mi intuición es que un bajo grado de entropía significaría que el código fuente reutiliza patrones comunes en toda la aplicación (es decir, DRY ). Por el contrario, un alto grado de entropía significaría que el código fuente es de alta complejidad y no se ha factorizado bien.
fuente
Una forma de pensar en la entropía es "obtener información promedio", por lo que creo que es mejor volver a modelar la información. Sé de dos enfoques básicos para modelar matemáticamente la información. (Perdóname por dar referencias de Wikipedia, pero en mi humilde opinión, no son malas).
Información de Shannon , que analiza los conjuntos de símbolos, las distribuciones de probabilidad de esos, los códigos que pueden transferir información entre los conjuntos de símbolos y las longitudes de esos códigos. Los conceptos generales de eficiencia de código, ruido, detección y corrección de errores mediante redundancia, etc. se expresan en términos de la teoría de la información de Shannon. Una forma de expresar información es decir que es la longitud del código binario más corto que podría representar un símbolo. Esto se basa en la probabilidad, que es un valor numérico asignado a un símbolo o evento por algún observador.
Información de Solomonoff (o Kolmogorov ). Aquí hay otra explicación. En esta formulación, el contenido de información de un símbolo o evento está representado por la longitud del programa más corto que podría calcularlo. Aquí nuevamente, es relativo, no a un observador que asigna probabilidad, sino a una máquina universal que puede ejecutar el programa. Dado que cada máquina universal puede ser simulada por una máquina de Turing universal, eso significa, en cierto sentido, que el contenido de información del símbolo o evento no es relativo, sino absoluto.
Si puedo tomarme la libertad de decir lo que creo que esto significa en términos cotidianos, sobre lo que escribí un libro , simplemente significa que la complejidad de un programa es su duración, cuando cosas como la especificación funcional y el lenguaje se mantienen constantes, con asignaciones para cosas como comentarios y longitudes de nombre. Pero hay un problema con esto: el "tarpit APL", donde la concisión es igual a la incomprensibilidad.
Es mucho mejor considerar (como lo hice mientras estudiaba IA) que la especificación funcional del programa consiste en un modelo mental, que no solo es real, sino que está codificado de manera eficiente, es decir, con una redundancia lo suficientemente pequeña que cambia la opinión sobre los requisitos. se puede hacer sin demasiado peligro de hacerlo internamente inconsistente, es decir, tener un "error". Entonces, el proceso de programación es un canal de información que toma como entrada el modelo mental, y su salida es el código fuente de trabajo. Luego, cuando se realiza un cambio en el modelo mental, ese delta debe alimentarse a través del proceso de programación y convertirse en un delta correspondiente en el código fuente. Ese delta se mide fácilmente. Diferencia la fuente entre antes de aplicar ese delta, y después de aplicarlo (completamente, con todos los errores resueltos), y cuente el número de bloques de código insertados, eliminados y reemplazados. Cuanto más pequeño es, mejor representa el lenguaje del código fuente el lenguaje en el que está representado el modelo mental (en términos de sustantivos, verbos y estructura). Si esa medida se promedia de alguna manera en el espacio de posibles cambios funcionales, ese es un concepto de entropía del lenguaje fuente, y menos es mejor. Hay un término para esto:Lenguaje específico de dominio (DSL)
Lo siento si las referencias son débiles / personales, pero creo que esta pregunta general es muy importante.
fuente
Jon Jagger y Olve Maudal tienen una visión ligeramente diferente de Code Entropy, como se puede ver en su sesión de conferencia Accu 2011 Code Entropy and Physics of Software .
Hablan sobre la estabilidad del código en relación a si los futuros desarrolladores / mantenedores pueden cambiar ese código.
Para demostrar esto, realizaron una encuesta con varios fragmentos de código y los resultados fueron bastante interesantes.
más 16 otros.
La tendencia general parecía ser hacer que el código sea más fácil de comprender y más difícil de comprender.
También analizan algunos de los cambios realizados en una gran base de código a lo largo de los años.
Aunque las diapositivas por sí solas no son una transcripción de la sesión, todavía hay algunos puntos interesantes allí.
fuente
Estudié con un profesor que usaba la entropía como una medida de la complejidad de los programas (nuestro libro de texto era una edición anterior de este , algunos de sus pubs están aquí ). Hubo una serie de disertaciones en FAU donde esta fue una de las principales medidas, pero el sitio web de la escuela ha cambiado desde la última vez que busqué, y no puedo localizar dónde se encuentran ahora las tesis / disertaciones de los estudiantes.
Una de estas tesis es la Teoría de la información y la Medición de software .
fuente
Si desea una definición que sea "mathy" en la forma en que lo es la entropía, es posible que desee ver la complejidad de Kolmogorov, que mide la complejidad por la cantidad mínima de código en la que podría hacerse algo. Sin embargo, esto no es complejidad del código, pero de lo que intentas hacer con el código. Pero podría pensar que es relevante porque, en teoría, podría comparar un fragmento de código particular con el mínimo. Sin embargo, esta no es actualmente una técnica útil para medir la complejidad del código del mundo real.
fuente
Creo que esto no es viable, se podría argumentar que una base de código bien escrita debería tener una mayor entropía (trastorno). Piense en una base de código donde el fragmento de código se repite una y otra vez, se puede comprimir con una alta relación de compresión debido a la repetición de la parte (menor entropía / tamaño de archivo), sin embargo, si mueve el código a una función separada, la relación de compresión será menor (mayor entropía / tamaño de archivo).
Entonces, uno puede pensar, entonces puedo calcular algo como Entropy / CodeLines usando la relación de compresión como coeficiente, para medir la calidad del código, sin embargo, esto tiene el problema de que la entrada aleatoria total se vería como el mejor código del mundo que obviamente no lo es.
De hecho, la relación de compresión es un buen medidor para medir la entropía del código, sin embargo, ambos no son buenos medidores para la calidad del código.
fuente
Bueno, el término entropía no solo aparece en la termodinámica y la teoría de la información, sino que también aparece en el mundo real de la compresión de datos. En ese contexto, la entropía que ve el compresor es igual al número de bits que produce. (Tenga en cuenta que dije "la entropía que ve el compresor ", porque lo que se considera entropía depende del modelo que utiliza el compresor para describir los datos de entrada. Esta es la razón por la cual diferentes compresores producen archivos de diferente tamaño: ¿Qué es la entropía para el compresor? uno es una estructura explotable para el otro.)
En principio, esto se puede aplicar maravillosamente a la complejidad del código fuente: "Simplemente" escriba un compresor que solo funcione en un código fuente que cumpla con los estándares y que lo comprima analizándolo realmente como lo haría un compilador, produciendo el árbol de sintaxis correspondiente. Luego puede recorrer este árbol de sintaxis y decidir en cada nodo qué nodos habrían sido posibles en cada punto, codificando ese nodo con ese conocimiento.
Entonces, por ejemplo, si el lenguaje permite un identificador existente, o algo encerrado entre paréntesis, o un producto en un punto específico, el compresor contaría los posibles identificadores existentes, teniendo en cuenta la información de tipo (digamos que tiene 3 de esos identificadores ), y agregue 2 para las dos subexpresiones posibles, dando 5 posibilidades. Entonces el nodo estaría codificado con
lb 5 = 2.32bits. En el caso de las dos subexpresiones posibles, se necesitarían más bits para codificar sus contenidos.De hecho, esto daría una medida muy precisa de la complejidad del código tal como es. ¡Sin embargo, esta medida sigue siendo inútil! Es inútil por la misma razón por la que todas las mediciones de complejidad del código son inútiles: fallan si trazan la conexión entre la complejidad del código medido (lo que sea que sea) y la complejidad del problema que resuelve el código. Se puede siempre encontrar soluciones ridículamente complejos a sus problemas de programación para impresionar a su empleador con el recuento de LOC, pero ninguna medida de la complejidad del código le dirá que la tarea podría haberse resuelto con una fracción del esfuerzo.
fuente
El código tiene exactamente tanta entropía como el número π.
El mantenimiento y el cambio de código pueden introducir entropía (porque hay un posible cambio de estado involucrado).
Pero el código es solo un gran número. Con una representación binaria.
fuente