Erros que podem ser evitados com os padrões de codificação [fechados]

Estou procurando estatísticas (ou estimativas) que apoiam a alegação de que os padrões de codificação ajudam a reduzir bugs. Números fixos seriam bons, embora eu não tenha olhado muito para encontrar nenhum. Eu até olhei o rastreamento de bugs para vários projetos de código aberto, mas não obtive muito sucesso ao encontrar o que eu preciso. Alguém aí conhece algum lugar em que eu possa encontrar isso? Ou algum de vocês contribui para projetos de código aberto que tiveram bugs que podem ter sido evitados com melhores padrões de codificação?

Os padrões de codificação por si só não reduzem bugs. Os padrões de codificação como parte de um processo sólido de desenvolvimento de software reduzem os bugs.

Aqui estão dois documentos que estudam o impacto estatístico do processo de engenharia de software de som na redução de defeitos que você pode usar como ponto de partida:

• Lista dos 10 principais da Redução de Defeitos de Software , que examina melhorias na engenharia de software empiricamente baseada desde 1987
• Uma Análise Crítica do Processo de Dados PSP , que estuda as estatísticas coletadas do Processo de Software Pessoal e o impacto do PSP nas causas comuns de erros de software

Codificação de "padrões" ... Existem muitas áreas de desenvolvimento que podem ser padronizadas. Estamos falando de convenções de codificação, como padrões de nomes etc? Ou estamos falando de algo mais profundo, como TDD / BDD, CI, etc?

Posso dizer que a adesão a uma metodologia de "primeiro teste", com o IC aplicando testes de aprovação e boa cobertura de código, reduz o número de bugs encontrados pelo cliente. O teste automatizado, tanto pelo desenvolvedor quanto pelo controle de qualidade, também é uma maneira relativamente "barata" de encontrar bugs, porque eles geralmente têm tempos de feedback muito curtos. Você pode saber que não escreveu o que pensou escrever executando cerca de 45 segundos de testes de unidade. Algumas horas de testes de integração encontrarão locais onde a conexão das coisas não correu como planejado, e os testes de interface do usuário automatizados de ponta a ponta podem detectar rapidamente falhas funcionais no software em níveis muito altos.

Eles também impedem a regressão. Você encontrou um bug. Você escreve um teste que comprova que o comportamento não ocorre mais, codifica até o teste passar e agora você tem um teste que, a partir deste momento, garantirá que o bug nunca mais seja um problema. Esta é, na minha experiência, uma fonte importante de novos bugs; a correção de uma coisa quebra outra coisa e o teste da correção do desenvolvedor pode não cobrir a outra situação que está quebrada. Quebrar coisas que costumavam trabalhar é uma enorme bandeira vermelha para seus clientes.

Por fim, essa estrutura de teste automatizada que você cria como parte dessa metodologia oferece muito facilmente um ambiente em que você pode lançar uma nova versão do software literalmente a qualquer momento. "Ei, esse bug que você acabou de corrigir está causando algumas dores de cabeça de verdade; quando você o terá pronto em uma nova versão?" clique em "Ah, em cerca de 5 minutos quando o servidor de compilação terminar de publicá-lo na página de download".

Quanto às convenções básicas de codificação, como a padronização de nomes de variáveis, etc., eu achei a maior parte disso menos útil e mais irritante. Esses são os tipos de padrões "maravilhosos, porque há muitos por onde escolher". O que você percebe como a diferença entre um identificador PascalCased e camelCased pode não ser o que alguém pensa. Sublinhados principais, limites de tamanho de nome (ou requisitos que os nomes de métodos / campos contam para uma história); além das convenções impostas pelo compilador ou que são comumente vistas no código da biblioteca específica do idioma, o IDE moderno pode dizer tudo o que você precisa saber sobre uma variável ou função, incluindo se você deve ou não tentar usá-lo em um determinado circunstância. Além disso, a execução de uma verificação de convenção de código geralmente retorna problemas com o código que você não pode ou não usa ' não deseja alterar, como uma biblioteca de terceiros que usava um conjunto diferente de padrões, ou código de interoperabilidade que pode estar em conformidade com os padrões de nomenclatura da API Win em vez dos padrões da sua língua nativa. Você acaba adicionando cruft ao seu código para dizer à sua ferramenta para ignorar o cruft no seu código.

Toda vulnerabilidade de injeção de SQL é um defeito que poderia ter sido evitado com um padrão de codificação. Estatísticas sobre vulnerabilidades de injeção SQL estão disponíveis, AFAIK.

Toda vulnerabilidade de estouro de buffer poderia ter sido evitada com um padrão de codificação. Estatísticas sobre esses provavelmente também estão disponíveis.