Bogues qui peuvent être évités avec les normes de codage [fermé]

Je recherche des statistiques (ou des estimations) qui corroborent l'affirmation selon laquelle les normes de codage aident à réduire les bogues. Les chiffres durs seraient bien, même si je n'ai pas beaucoup cherché à en trouver. J'ai même examiné le suivi des bogues pour divers projets open source, mais je n'ai pas réussi à trouver ce dont j'avais besoin. Quelqu'un connaît-il un endroit où je pourrais trouver cela? Ou l'un de vous contribue-t-il à des projets open source qui ont eu des bugs qui auraient pu être évités avec de meilleures normes de codage?

Les normes de codage ne réduisent pas à elles seules les bogues. Les normes de codage dans le cadre d'un processus de développement logiciel sain réduisent les bogues.

Voici deux articles qui étudient l'impact statistique du processus de génie logiciel sur la réduction des défauts que vous pouvez utiliser comme point de départ:

• Liste des 10 principaux logiciels de réduction des défauts , qui recense les améliorations apportées à l'ingénierie logicielle empirique depuis 1987
• Une analyse critique du processus de données PSP , qui étudie les statistiques collectées à partir du processus logiciel personnel, et l'impact de PSP sur les causes courantes des erreurs logicielles

Codage des "normes" ... Il existe de nombreux domaines de développement qui peuvent être normalisés. Parlons-nous de conventions de codage, comme les normes de dénomination, etc.? Ou parlons-nous de quelque chose de plus profond, comme TDD / BDD, CI, etc.?

Je peux vous dire que l'adhésion à une méthodologie "test-first", avec CI imposant des tests réussis et une bonne couverture de code, réduit le nombre de bogues trouvés par le client. Les tests automatisés, à la fois par le développeur et le contrôle qualité, sont également un moyen relativement "bon marché" de trouver des bogues car ils ont généralement des temps de retour très courts. Vous pouvez savoir que vous n'avez pas écrit ce que vous pensiez avoir écrit en exécutant environ 45 secondes de tests unitaires. Quelques heures de tests d'intégration trouveront des endroits où les choses ne se sont pas déroulées comme prévu, et des tests d'interface utilisateur de bout en bout et automatisés peuvent rapidement détecter des défauts fonctionnels dans le logiciel à des niveaux très élevés.

Ils empêchent également la régression. Vous avez trouvé un bug. Vous écrivez un test qui prouvera que le comportement ne se produit plus, vous codez jusqu'à ce que le test réussisse, et maintenant vous avez un test qui assurera à partir de ce moment que le bogue ne sera plus jamais un problème. C'est, selon mon expérience, une source majeure de nouveaux bogues; corriger une chose rompt quelque chose d'autre, et votre développeur testant le correctif peut ne pas couvrir cette autre situation qui est maintenant cassée. Briser des trucs qui fonctionnaient était un ÉNORME drapeau rouge pour vos clients.

Enfin, cette structure de test automatisée que vous construisez dans le cadre de cette méthodologie vous donnera très facilement un environnement où vous pourrez publier une nouvelle version du logiciel à la lettre. "Hé, ce bug que vous venez de corriger a causé de vrais maux de tête; quand l'aurez-vous prêt dans une nouvelle version?" cliquez sur "Oh, dans environ 5 minutes lorsque le serveur de build a fini de le publier sur la page de téléchargement".

En ce qui concerne les conventions de codage de base, comme la normalisation des noms de variables, etc., j'ai trouvé que la plupart de celles-ci étaient moins utiles et plus irritantes. Ce sont des types de normes qui sont "formidables, car il y a tellement de choix". Ce que vous percevez comme la différence entre un identifiant PascalCased et camelCased peut ne pas être ce que quelqu'un d'autre pense. Soulignés principaux, limites de longueur des noms (ou exigences que les noms de méthode / champ racontent une histoire); autres que les conventions imposées par le compilateur ou couramment utilisées dans le code de bibliothèque spécifique à la langue, l'EDI moderne peut vous dire tout ce que vous devez savoir sur une variable ou une fonction, y compris si vous devez ou non essayer de l'utiliser dans un contexte particulier circonstance. En outre, l'exécution d'une vérification de convention de code renvoie souvent des problèmes avec du code que vous ne pouvez pas ou ne parvenez pas à faire. Je ne veux pas changer, comme une bibliothèque tierce qui utilise un ensemble de normes différent, ou un code d'interopérabilité qui peut être conforme aux normes de dénomination de l'API Win au lieu des normes de votre langue maternelle. Vous finissez par ajouter de la cruauté à votre code pour dire à votre outil d'ignorer la cruauté de votre code.

Chaque vulnérabilité d'injection SQL est un défaut qui aurait pu être évité avec une norme de codage. AFAIK, des statistiques sur les vulnérabilités d'injection SQL sont disponibles.

Chaque vulnérabilité de dépassement de tampon aurait pu être évitée avec une norme de codage. Des statistiques à ce sujet sont probablement également disponibles.