O conceito de Entropia pode ser usado para analisar o código-fonte de uma maneira útil?

Parece-me lógico que alguém possa definir um contexto para a análise estática do código-fonte que inclua regras para produzir um valor relativo de complexidade. Eu sei que não é assim no sentido físico, porque o código da fonte não tem "Energia", mas aposto que houve esforços, pelo menos acadêmicos, para traçar um paralelo. Alguém tem conhecimento disso e, em caso afirmativo, com que finalidade produziu resultados úteis?

Já existem várias medidas de complexidade de código:

• Complexidade ciclomática
• Duração da turma
• Comprimento do método
• número de campos
• Número de parâmetros do método
• Complexidade do caminho N
• Fan-in e fan-out
• Análise de fluxo de dados (cadeias DU / DD)

Foi feito um trabalho para correlacioná-los com defeitos de densidade, esforço para manter e facilidade de entendimento. Alguns são mais significativos que outros, dependendo do que você está tentando aprender com sua análise. Não estou tão familiarizado com o conceito de entropia das ciências físicas, mas me pergunto se rastrear medições e métricas como as que eu nomeei ao longo do tempo e relacioná-las com defeitos ao longo do tempo seria semelhante ao que você está procurando.

Você pode também estar interessado na definição de entropia e podridão de software de Ivar Jacobson . A idéia geral desses tópicos é que, com o tempo, à medida que o código e o ambiente de execução mudam, o sistema de software começa a se degradar. A refatoração é vista como um método para minimizar a entropia ou podridão e, pelo menos em minhas experiências, as métricas e medidas que mencionei acima seriam indicadores de que a refatoração pode ser necessária em um sistema ou subsistema.

Acho que você está tentando traçar um paralelo entre entropia termodinâmica e "complexidade". A questão é que a entropia é uma medida de desordem, não de complexidade . Não acredito que os dois sejam equivalentes e intercambiáveis.

O análogo mais próximo da entropia termodinâmica é a entropia de Shannon, que mede a quantidade de desordem em uma variável aleatória. Essa noção se preocupa principalmente com a quantidade de "informações" em uma mensagem.

Nesse sentido, um pedaço de código pode ter muitas informações (alta entropia), mas com complexidade muito baixa. Pense em um programa que simplesmente imprima uma série muito longa de caracteres arbitrários. Tem muita informação, mas baixa complexidade.

Entropia é uma "medida de desordem [ou] imprevisibilidade". Uma gama mais ampla de padrões únicos nas informações (isto é, aproximadamente "mais significado") indica um maior grau de entropia.

Aplicado ao código fonte do computador, acho que esse princípio pode ser útil. No entanto, seria necessário projetar um modelo probabilístico para o código-fonte com o qual calcular a entropia. (Uma estrutura de dados que vem à mente é um gráfico com diferentes tipos de borda: chamada, herança de classe etc.)

Uma vez que o modelo é projetado e preenchido com o código fonte de um aplicativo de software (ou seja, frequências para nós / arestas), a entropia pode ser calculada.

Não conheço nenhuma pesquisa sobre isso, mas minha intuição é que um baixo grau de entropia significaria que o código fonte reutiliza padrões comuns em todo o aplicativo (por exemplo, DRY ). Por outro lado, um alto grau de entropia significaria que o código fonte é de alta complexidade e não foi fatorado adequadamente.

Uma maneira de pensar em entropia é "informações médias a serem obtidas", então acho que é melhor voltar à modelagem de informações. Conheço duas abordagens básicas para modelar matematicamente as informações. (Perdoe-me por fornecer referências à Wikipedia, mas IMHO não são ruins.)

• Informações de Shannon , que analisam conjuntos de símbolos, distribuições de probabilidade nesses, códigos que podem transferir informações entre conjuntos de símbolos e comprimentos desses códigos. Os conceitos gerais de eficiência de código, ruído, detecção e correção de erros via redundância etc. são apresentados em termos da teoria da informação de Shannon. Uma maneira de expressar informações é dizer que é o comprimento do menor código binário que pode representar um símbolo. Isso é baseado na probabilidade, que é um valor numérico atribuído a um símbolo ou evento por algum observador.

• Informações de Solomonoff (ou Kolmogorov ). Aqui está outra explicação. Nesta formulação, o conteúdo de informações de um símbolo ou evento é representado pela duração do programa mais curto que pode ser calculado. Aqui, novamente, é relativo, não a um observador que atribui probabilidade, mas a uma máquina universal que pode executar o programa. Como toda máquina universal pode ser simulada por uma máquina de Turing universal, isso significa, em certo sentido, que o conteúdo de informação do símbolo ou evento não é relativo, mas absoluto.

Se posso ter a liberdade de dizer o que acho que isso significa em termos cotidianos, sobre o qual escrevi um livro , significa simplesmente que a complexidade de um programa é sua duração, quando coisas como a especificação funcional e a linguagem são mantidas constantes, com a devida adequação. permissões para coisas como comentários e comprimentos de nomes. Mas há um problema com isso - o "tarpit APL", onde concisão é igual a incompreensibilidade.

É muito melhor considerar (como eu estudava a IA) que as especificações funcionais do programa consistem em um modelo mental, que não é apenas real, mas codificado de forma eficiente, ou seja, com redundância pequena o suficiente para mudar de idéia sobre os requisitos Isso pode ser feito sem muito risco de torná-lo internamente inconsistente - ou seja, com um "bug". Então, o processo de programação é um canal de informação que toma como entrada o modelo mental e sua saída é o código-fonte de trabalho. Então, quando uma alteração é feita no modelo mental, esse delta deve ser alimentado através do processo de programação e transformado em um delta correspondente no código-fonte. Esse delta é facilmente medido. Diferencie a fonte antes de aplicar esse delta e depois de aplicá-lo (completamente, com todos os bugs resolvidos), e conte o número de blocos de código inseridos, excluídos e substituídos. Quanto menor, melhor a linguagem do código-fonte representa a linguagem na qual o modelo mental é representado (em termos de substantivos, verbos e estrutura). Se essa medida é, de alguma forma, calculada a média do espaço de prováveis ​​mudanças funcionais, esse é um conceito de entropia do idioma de origem e menos é melhor. Há um termo para isso -Linguagem Específica de Domínio (DSL)

Sinto muito se as referências são fracas / pessoais, mas acho que essa questão geral é muito importante.

Jon Jagger e Olve Maudal têm uma visão um pouco diferente da Code Entropy, como pode ser visto em sua sessão de conferência da Accu em 2011 Code Entropy e Physics of Software .

Eles falam sobre a estabilidade do código estar relacionada à probabilidade de futuros desenvolvedores / mantenedores alterarem esse código.

Para demonstrar isso, eles realizaram uma pesquisa com vários trechos de código e os resultados foram bastante interessantes.

• Parecia haver um forte viés contra o estilo de cinta única .
• Mas um forte viés para adotar uma única declaração se é.
• Houve um forte viés contra o uso de variáveis ​​temporárias.
• Havia um forte viés para adicionar parênteses para tornar óbvia a precedência do operador.

mais 16 outros.

A tendência geral parecia ser a de tornar o código mais fácil de entender e mais difícil de entender mal.

Eles também analisam algumas das alterações feitas em uma grande base de código ao longo dos anos.

Embora os slides por si só sofram de não serem uma transcrição da sessão, ainda existem alguns pontos interessantes.

Estudei com uma professora que usou entropia como uma medida da complexidade dos programas (o nosso livro era uma edição mais antiga de um presente , alguns de seus bares estão aqui ). Houve uma série de dissertações na FAU, onde essa foi uma das principais medidas, mas o site da escola mudou desde a última vez que eu procurei, e não consigo localizar onde estão as teses / dissertações dos alunos.

Uma dessas dissertações é a Teoria da Informação e a Medição de Software .

Se você deseja uma definição "mathy" da maneira que a entropia é, consulte a complexidade de Kolmogorov, que mede a complexidade pela quantidade mínima de código em que algo poderia ser feito. No entanto, isso não é complexidade de código, mas do que você está tentando fazer com o código. Mas você pode pensar que é relevante porque, teoricamente, você pode comparar um pedaço de código específico com o mínimo. No entanto, atualmente não é uma técnica útil para medir a complexidade do código do mundo real.

Eu acho que isso não é viável, alguém poderia argumentar que uma base de código bem escrita deve ter maior entropia (desordem). Pense em uma base de código onde o trecho de código é repetido várias vezes, ele pode ser compactado com alta taxa de compactação devido à parte repetida (menor entropia / tamanho do arquivo); no entanto, se você mover o código para uma função separada, a taxa de compactação será menor (maior entropia / tamanho do arquivo).

Então, pode-se pensar, então eu posso calcular algo como Entropy / CodeLines usando a taxa de compressão como coeficiente, para medir a qualidade do código, no entanto, isso tem o problema de que a entrada aleatória total pareceria o melhor código do mundo que obviamente não é.

De fato, a taxa de compressão é um bom medidor para medir a entropia do código, no entanto, ambos não são bons medidores para a qualidade do código.

Bem, o termo entropia não aparece apenas na termodinâmica e na teoria da informação, mas também no mundo real da compactação de dados. Nesse contexto, a entropia que o compressor vê é igual ao número de bits que produz. (Observe que eu disse "a entropia que o compressor vê ", porque o que é considerado entropia depende do modelo que o compressor usa para descrever os dados de entrada. Essa é a razão pela qual diferentes compressores produzem arquivos de tamanho diferente: O que é entropia para o compressor um é estrutura explorável para o outro.)

Isso pode, em princípio, ser lindamente aplicado à complexidade do código-fonte: "Apenas" escreva um compressor que só funcione em código-fonte totalmente compatível e que o comprima realmente analisando-o como um compilador, produzindo a árvore de sintaxe correspondente. Em seguida, ele pode percorrer essa árvore de sintaxe e decidir em cada nó quais nós seriam possíveis em cada ponto, codificando esse nó com esse conhecimento.

Assim, por exemplo, se o idioma permitir um identificador existente ou algo entre parênteses ou um produto em um ponto específico, o compressor contará os possíveis identificadores existentes, levando em consideração as informações de tipo (digamos que você tenha 3 desses identificadores) ) e adicione 2 para as duas subexpressões possíveis, oferecendo 5 possibilidades. Portanto, o nó seria codificado com lb 5 = 2.32bits. No caso das duas subexpressões possíveis, seriam necessários mais bits para codificar seu conteúdo.

Isso realmente daria uma medida muito precisa para a complexidade do código como ele é. No entanto, essa medida ainda é inútil! É inútil pela mesma razão que todas as medidas de complexidade de código são inúteis: elas falham na conexão entre a complexidade de código medida (o que quer que seja) e a complexidade do problema que o código resolve. Você sempre pode encontrar soluções ridiculamente complexas para seus problemas de programação para impressionar seu empregador com suas contagens de LOC, mas nenhuma medida de complexidade de código dirá que a tarefa pode ter sido resolvida com uma fração do esforço.

O código tem exatamente a mesma entropia que o número π.

A manutenção e alteração de código podem introduzir entropia (porque há uma possível alteração de estado envolvida).

Mas o código é apenas um grande número. Com uma representação binária.