O número médio de bugs por local é o mesmo para diferentes linguagens de programação? [fechadas]

Foi-me dito que o número médio de bugs / defeitos por linha de código é "constante" para diferentes linguagens de programação. 10 KLOC de Ruby teriam o mesmo número de bugs que 10 KLOC de c ++. O argumento geralmente é usado para promover o uso de linguagens expressivas (pense em python / ruby ​​sobre c ++ / assembly), pois o número de linhas para descrever a mesma funcionalidade seria menor.

Alguém sabe de onde vem essa afirmação? Os idiomas de nível superior levam a menos erros?

Ao contrário da intuição, o número de erros por 1.000 linhas de parece ser relativamente constante, independentemente do idioma específico envolvido. Steve McConnell , autor de Code Complete e Software Estimation: Demystifying the Black Art, aborda essa área com mais detalhes.

Não tenho minhas cópias prontamente disponíveis - elas estão sentadas na minha estante de trabalho - mas um rápido Google encontrou uma citação relevante:

Média da indústria: "cerca de 15 a 50 erros por 1.000 linhas de código entregue".
(Steve) ainda diz que isso geralmente representa um código que possui algum nível de programação estruturada, mas provavelmente inclui uma mistura de técnicas de codificação.

Citado em Code Complete , encontrado aqui: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Se a memória funciona corretamente, Steve entra em uma discussão completa sobre isso, mostrando que os números são constantes nas linguagens (C, C ++, Java, Assembly e assim por diante) e apesar das dificuldades (como definir o que significa "linha de código").

Mais importante ainda, ele tem muitas citações para suas fontes - ele não está oferecendo opiniões sem fundamento, mas tem as referências para apoiá-las.

Parece que tudo se resume a isso: o número médio de defeitos por kloc parece ser mais uma propriedade do fato de que os desenvolvedores são seres humanos falíveis do que das vantagens ou desvantagens peculiares de uma determinada linguagem ou plataforma.

(Além disso: se você ainda não possui o Código Completo, compre uma cópia e leia-a completamente - vale a pena o investimento.)

Atualização : Há outro fator em jogo com algumas das respostas aqui: estatísticas em larga escala são úteis para fazer previsões gerais, mas não específicas. Considere que as tabelas de mortalidade populacional podem prever quantas pessoas serão mortas em acidentes de trânsito este ano, mas não podem dizer quais pessoas morrerão. Da mesma forma, as estatísticas do setor que mostram um número relativamente constante de defeitos por kloc não podem ser usadas para prever quão bem - ou quão mal - um determinado desenvolvedor irá executar ou o que acontecerá em um determinado projeto.

A alegação é - na melhor das hipóteses - ingênua.

O SLOC não é exatamente uma métrica confiável para qualquer coisa útil, exceto talvez comparar o tamanho de dois ou mais projetos. Além disso, existem dois tipos distintos de SLOC, LOC físico e LOC lógico, e esses podem diferir significativamente. Considere este exemplo, da Wikipedia :

for (i = 0; i < 100; i += 1) printf("hello"); 

Aqui temos um LOC físico, mas dois lógicos ( fore printfinstruções). Mas é claro que poderíamos escrever o exemplo como:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

O que nos daria dois LOCs físicos e dois lógicos. Eu acho que é claro que qualquer medida "bug por local" que dependa de LOCs físicos seria contaminada pelo estilo de programação, portanto, nossa medida seria amplamente inútil.

Se, por outro lado, adotássemos LOCs lógicos, nossa medição dependeria muito das idiossincrasias sintáticas da linguagem. Embora a métrica resultante possa ser um pouco útil ao comparar projetos escritos no mesmo idioma, seria bastante inútil para projetos escritos em idiomas diferentes.

Uma fonte possível para a reivindicação são as falhas-loucuras e falácias do software da Les Hatton :

Podemos concluir que a escolha da linguagem de programação está na melhor das hipóteses relacionada à confiabilidade.

Posteriormente, o artigo menciona densidades semelhantes de defeitos para C e C ++:

Em um estudo recente que comparou dois sistemas semelhantes de tamanho semelhante (cerca de 50.000 linhas cada), um em C e um em C ++ projetado por objeto, as densidades de defeitos resultantes mostraram ser aproximadamente as mesmas em 2,4 e 2,9 por 1.000 linhas, respectivamente.

Isso, no entanto, não significa que o "bug por LOC" seja constante nas linguagens de programação ou que seria significativo se fosse.

Essa observação é muito antiga e vem de uma fonte muito venerável, a saber, Fred Brooks em seu livro "The Mythical Man Month". Ele foi um dos principais gerentes da IBM e gerenciou muitos projetos de programação, incluindo o sistema operacional de milhões de linhas OS / 360. De fato, ele relatou que o número de bugs em um programa não é proporcional ao comprimento do código, mas quadrático ! Segundo sua pesquisa, o número de bugs foi proporcional à duração do programa e à potência 1.5. Em outras palavras, um programa dez vezes maior tem 30 vezes mais bugs. E ele relatou que isso ocorria em todas as linguagens de programação e níveis de linguagens de programação.

Não acho que os bugs por LOC sejam constantes para um determinado idioma. Os bugs por LOC parecem uma métrica usada por alguns gerentes para determinar a qualidade dos desenvolvedores na hora de revisar.

Agora, fora isso, alguns idiomas são mais propensos a erros ou defeitos do que outros. Geralmente, mas nem sempre, esse é um idioma de nível inferior ao do idioma mais alto. Por exemplo, codificação em C versus C # (ou Java.) Digo normalmente porque a realidade e o ponto crucial da resposta que você procura se resume à qualidade do desenvolvedor e às práticas de codificação em vigor. Vi desenvolvedores C muito bons, com qualidade de código muito mais alta e contagens de defeitos mais baixas do que os desenvolvedores comuns de Java / C #. Esse é um item que separa um desenvolvedor sênior de um desenvolvedor júnior. Não quantos LOC eles escrevem em um determinado período de tempo, mas a qualidade do código que eles escrevem, independentemente do idioma, LOC ou período de tempo.

A única coisa que posso dar e que pode se relacionar é que quanto mais LOC houver, maior a probabilidade de que haja um defeito e mais defeitos existam.

Erros por linha de código

Bugs / LOC é apenas relativo a um indivíduo. Para empresas que implementam ferramentas de rastreamento de bugs vinculadas ao repositório de código-fonte. É possível que um gerente organize problemas por desenvolvedor, classificados por problemas anteriores e alterações de código.

Os bugs são relativos ao seu trabalho

Um desenvolvedor de software sênior, altamente experiente, altamente qualificado, muito inteligente e capaz de assumir tarefas independentes, tem muito mais chances de ter muito mais bugs registrados em um sistema de rastreamento, depois um desenvolvedor júnior com pouca experiência.

Como isso é possível?

Os desenvolvedores seniores geralmente estão envolvidos em tarefas de desenvolvimento de alto risco. Refatoração de código e construção de novos sistemas como exemplo. Os desenvolvedores juniores geralmente são designados para corrigir problemas conhecidos que não valem o tempo de um desenvolvedor sênior.

Portanto, por atribuição de tarefa, um júnior não está introduzindo bugs, mas corrigindo-os, e um desenvolvedor sênior tem o risco de apresentá-los, porque o benefício do que eles estão tentando arquivar é mais importante do que os problemas menores que são levantados para concluir esses tarefas.

A sintaxe do idioma é importante

O argumento de que uma linguagem introduz menos erros, porque pode obter mais em menos linhas de código, é um mito completo. Linguagens altamente estruturadas como C ++ / C # / Java forçam o desenvolvedor a expressar claramente por escrito qual deve ser a instrução desejada, onde linguagens como Python / PHP são muito desestruturadas. Esses idiomas permitem expressões escritas que não apenas confundem um desenvolvedor, mas também o analisador de idiomas.

O compilador reduz erros

Quantos bugs no Python / PHP chegaram aos servidores de produção, porque não havia um compilador para avisar o desenvolvedor que algo estava incorreto. Quando você mede bugs por LOC, isso ocorre antes ou depois de um compilador ter processado o código-fonte?

Atualização 2019:

Os compiladores não fazem diferença na natureza ou no número de bugs. Os bugs são puramente relativos à pessoa que escreveu o código fonte, e os bugs em si podem ser de natureza muito subjetiva.

FWIW, na minha experiência

1. Existem dois tipos de erros: a) em que o programa não atende às expectativas eb) em que o programa não pode atender a expectativas razoáveis, porque trava / trava / não é compilado.

2. Independentemente do idioma, os erros do tipo (b) são causados ​​por redundância na estrutura de dados / classe, onde a alteração de algo em uma parte da estrutura de dados coloca a estrutura em um estado inconsistente / interrompido até que uma ou mais alterações correspondentes sejam feitas em outras partes. . Contribuir para isso é a redundância do código-fonte, onde uma edição em uma linha de código torna o código incorreto até que uma ou mais alterações sejam feitas em outras partes. Esses dois tipos de redundância estão intimamente relacionados, é claro, e como os programadores não são superpessoas, eles se distraem, esquecem coisas e cometem erros, colocando erros.

Essas coisas (novamente, na minha experiência) não são realmente uma função da linguagem, mas da habilidade / maturidade do programador. Programas muito menos propensos a erros também tendem a ser muito menores, em termos de LOC, para um determinado conjunto de funcionalidades.

Eu já vi sistemas em que algumas pessoas escrevem programas, enquanto outras escrevem diretórios, e o primeiro tende a "simplesmente funcionar" em comparação com o último.

Eu esperaria que um fator-chave nos erros de codificação estivesse relacionado ao que eu chamo de "lacuna semântica" entre um tipo específico de definição de solução e o código para resolvê-lo - onde estes são erros de reformulação próximos, seria mais aparente, onde o código é muito diferente, muitos erros podem ser esperados. O paradigma de certas linguagens se aproxima muito de certos domínios problemáticos - as planilhas são muito apropriadas para os cálculos comerciais diários, resultando em muito pouco "código" e "código" muito próximos do domínio do problema. O código esperado é muito conciso (pouco KLOC) e poucos erros. Por outro lado, o uso do assembler exigiria muitos KLOC e provavelmente produzirá um número imenso de erros.

Em vez de falar sobre linhas de código - que são de fato uma métrica inútil - eu gostaria de abordar esta parte da sua pergunta:

Os idiomas de nível superior levam a menos erros?

Isso é diferente de bugs / LOC, porque idiomas de nível superior fazem mais com menos código. A implementação de alguns requisitos de recursos pode levar 500 linhas de LISP versus 15.000 linhas de montagem x86.

Portanto, mesmo que bugs / LOC seja constante entre todos os idiomas, o idioma de nível superior ainda produzirá menos bugs.