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 ( for
e printf
instruçõ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.