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


45

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?


11
Parece irracional, considerando que alguns idiomas incentivam um estilo que agrupa mais declarações em uma única linha do que outros.
Calebe

10
Bugs / LOC é uma métrica muito errada para tudo. Depende da linguagem, mas depende muito mais do programador, da escrita. Portanto, fazer a média da linguagem não faz sentido, pois as grandes flutuações estão na outra variável. Isso é apenas IMO, ofc.
27568 KFreff:

3
Posso dizer que o número de bugs / linha que escrevo em Perl será muito maior que o número em C. Um amigo meu é um assistente de Perl, e para ele os bugs / linhas são muito maiores em C do que em Perl. Difícil ver como essa métrica poderia ser útil.
Calebe


2
Acabei de me deparar com essa pergunta. Não sei o porquê de estar fechado; Esta é uma pergunta perfeita para este site. Para um projeto grande, os bugs por KLOC não são uma medida de quão bons são os programadores. É uma medida de quão boa a organização e o processo são.
David Hammen

Respostas:


43

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.


4
Não tenha uma cópia da Estimativa de software, mas no Code Complete McConnel cita o relatório Capers Jones "Qualidade do programa e produtividade do programador", 1977, como a fonte de uma tabela de erros por LOC por tamanho de projeto. O ponto que McConnel tenta fazer é que os erros aumentam drasticamente à medida que o tamanho do projeto aumenta e observa que os dados são apenas um "instantâneo da indústria" e que "os números podem ter pouca semelhança com os dos projetos nos quais você trabalhou. " Realmente não vejo nada que tenha algo a ver com essa pergunta.
Roc Martí

Qual edição do Code Complete você tem @ RocMartí? Eu sei que a segunda edição foi uma grande atualização. Vou ter que desenterrá-lo e ver o que diz quando chegar ao trabalho na segunda-feira.
Bevan

Eu acho que sua edição ( Update :) é o núcleo do problema. Ou, como Mark Twain disse, existem três tipos de mentiras: Mentiras, Mentiras e Estatísticas.
GalacticCowboy

1
@ RocMartí "erros aumentam drasticamente à medida que o tamanho do projeto aumenta" Ele também apontou que a água está molhada? Claro que há erros quando as coisas ficam mais complicadas. Porque toda nova mudança deve ter em mente todas as peças possíveis que possam ser afetadas. O que cresce à medida que o projeto cresce.
Parthian Shot

3
A cotação está incorreta ou desatualizada. Na segunda edição, está na página 521: "A experiência média do setor é de 1 a 25 erros por 1.000 linhas de código para o software entregue. O software geralmente foi desenvolvido usando uma mistura de técnicas".
Aryeh Leib Taurog

18

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.


Se você assumir que bugs / declaração é constante, há uma diferença para os idiomas. O exemplo C geralmente possui bugs nos argumentos for () e printf (). Se você tivesse que codificar completamente a funcionalidade printf, teria proporcionalmente mais bugs e se tivesse um idioma de nível superior com uma única chamada printRepeat (), haveria menos oportunidades de errar.
Martin Beckett

2
Resumo: os bugs por ponto de instrução / função são constantes, as linguagens de baixo nível têm mais código escrito pelo programador falível, as linguagens de alto nível que você digita menos - portanto, menos bugs. Embora os erros do tipo de projeto totalmente incorretos sejam provavelmente os mesmos!
Martin Beckett

2
Muito menos que o que constitui "um bug" seja altamente subjetivo e que os erros diferem muito em gravidade, impacto e importância.
tdammers

@ Tdammers E essa importância pode ser negativa. Temos um punhado de bugs que o cliente é usado para / espera / quer, por isso não podemos corrigi-los ...
Izkata

@Izkata: depende de sua definição de um erro ...
tdammers

12

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.


6

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.


Minha pergunta é sobre o número médio de defeitos por linha de código, independentemente da linguagem.
21913 Kristian

4
@ Kristian não existe esse número. Isso muda por pessoa em relação ao trabalho e à experiência do desenvolvedor e ao idioma em que eles estão codificando. Não acho que exista uma média universal.
precisa saber é o seguinte

1
@ Akira71 "não existe esse número" Bem, com certeza. Mas existem distribuições de probabilidade, das quais você pode extrair números. Também não há número para quantas polegadas de chuva caem anualmente na floresta amazônica, mas você pode fazer uma média.
Parthian Shot

3

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.


3
Re-compilador reduzindo erros: Tanto o Python quanto o PHP tecnicamente possuem compiladores, eles simplesmente não fazem a mesma verificação que as linguagens de tipo estaticamente. Também não concordo que essa verificação tenha um efeito significativo na contagem final de erros, porque praticamente todos os erros que podem ser capturados por um compilador são detectados com o mínimo de testes.
Winston Ewert 02/02

3
Concordou que os erros que poderiam ser detectados pelo compilador geralmente são detectados com testes automatizados ou manuais razoáveis. A diferença é que as linguagens de tipo estaticamente fornecem a primeira aprovação no teste (a) de graça e (b) muito, muito rapidamente. Um bom conjunto de testes de unidade Ruby é melhor que um compilador, mas geralmente você não pode executá-los tão rápido, não os obtém de graça, e eles normalmente não apontam tão perto da linha de código que é o problema.
21715 Ken

Os tipos estáticos do @KenSmith não são gratuitos. cursos.cs.washington.edu/courses/cse590n/10au/…
Hugo Wood

1

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.


1

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.


como isso foi prejudicado? SO está se tornando cheio de palhaços
codyc4321

0

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.


2
Linhas de código uma "métrica inútil"? Não, é uma aproximação aproximada da complexidade do programa. Pode ser útil porque é fácil de medir e também está intimamente relacionado ao tempo de desenvolvimento.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.