Kodlama standartlarıyla önlenebilecek hatalar [kapalı]

Kodlama standartlarının hataları azaltmaya yardımcı olduğu iddiasını yedekleyen istatistikler (veya tahminler) arıyorum. Zor rakamlar iyi olurdu, ancak çok fazla bir şey bulamamıştım. Çeşitli açık kaynaklı projeler için hata izlemeye bile baktım, ancak ihtiyacım olanı bulmakta başarılı olamadım. Orada bulabileceğim herhangi bir yer bilen var mı? Veya herhangi biriniz daha iyi kodlama standartlarıyla önlenebilecek hatalara sahip herhangi bir açık kaynaklı projeye katkıda bulunuyor musunuz?

Standartları kendi başlarına kodlamak hataları azaltmaz. Sağlam bir yazılım geliştirme sürecinin bir parçası olarak standartları kodlamak hataları azaltır.

Ses yazılım mühendisliği sürecinin başlangıç ​​noktası olarak kullanabileceğiniz hata azaltma üzerindeki istatistiksel etkisini inceleyen iki makale:

• 1987'den beri ampirik tabanlı yazılım mühendisliğindeki gelişmeleri araştıran Yazılım Hata Azaltma İlk 10 Listesi
• Kişisel Yazılım Sürecinden toplanan istatistikleri ve PSP'nin yazılım hatalarının yaygın nedenleri üzerindeki etkisini inceleyen PSP Veri Sürecinin Eleştirel Analizi

"Standartları" kodlamak ... Standartlaştırılabilecek birçok geliştirme alanı vardır. Standartları adlandırmak gibi kodlama kurallarından mı bahsediyoruz? Yoksa TDD / BDD, CI gibi daha derin bir şeyden mi bahsediyoruz?

Size "ilk test" metodolojisine uymanın, CI'yi geçen testleri ve iyi kod kapsamını zorunlu kılma ile, müşterinin bulduğu hata sayısını azalttığını söyleyebilirim. Hem geliştirici hem de KG tarafından otomatikleştirilmiş testler de hataları bulmanın nispeten "ucuz" bir yoludur, çünkü genellikle çok kısa geri bildirim süreleri vardır. 45 saniye değerinde birim testleri yaparak yazdıklarını düşündüğünüzü yazmadığınızı biliyorsunuz. Birkaç saatlik entegrasyon testleri, bir şeyleri bir araya getirmenin planlandığı gibi gitmediği yerleri bulacak ve uçtan uca ve otomatik UI testi, yazılımdaki işlevsel hataları çok yüksek seviyelerde hızla tespit edebiliyor.

Ayrıca regresyonu önlerler. Bir hata buldunuz. Bu davranışın artık gerçekleşmediğini kanıtlayacak bir test yazıyorsunuz, test geçene kadar kod yazıyorsunuz ve şimdi bu noktadan sonra hatanın bir daha asla sorun olmayacağını garanti edecek bir testiniz var. Bu, benim tecrübelerime göre, önemli bir yeni hata kaynağıdır; bir şeyi düzeltmek başka bir şeyi bozar ve geliştiricinin düzeltmeyi sınaması, şimdi kırılan diğer durumu kapsamıyor olabilir. Eskiden işe yarayan şeyleri kırmak müşterilerinize BÜYÜK bir kırmızı bayraktır.

Son olarak, bu metodolojinin bir parçası olarak oluşturduğunuz bu otomatik test yapısı, yazılımın yeni bir yapısını tam anlamıyla bir an önce yayınlayabileceğiniz bir ortam sağlayacaktır. "Hey, düzelttiğiniz bu hata bazı gerçek baş ağrılarına neden oluyor; bunu yeni bir versiyonda ne zaman hazırlayacaksınız?" "Yapı sunucusu indirme sayfasına yayınlamayı tamamladığında yaklaşık 5 dakika içinde" seçeneğini tıklayın .

Değişken isimlerini standartlaştırmak gibi temel kodlama kurallarına göre, bunların çoğunun daha az kullanışlı ve daha rahatsız edici olduğunu gördüm. Bunlar "harika, çünkü aralarından seçim yapabileceğiniz çok şey var" gibi standartlar. PascalCased ve camelCased tanımlayıcısı arasındaki fark olarak algıladığınız şey, başka birinin düşündüğü şey olmayabilir. Başlıca alt çizgiler, ad uzunluğu sınırları (veya yöntem / alan adlarının bir hikaye anlattığı gereksinimler); derleyici tarafından uygulanan veya dile özgü kütüphane kodunda yaygın olarak görülen kurallar dışında, modern IDE, bir değişken veya işlev hakkında bilmeniz gereken her şeyi, belirli bir şekilde kullanmanız gerekip gerekmediği de dahil olmak üzere size söyleyebilir durum. Buna ek olarak, bir kod düzenleme denetimi çalıştırmak genellikle yapamayacağınız veya yapamayacağınız kodla ilgili sorunları döndürecektir Farklı bir standartlar dizisi kullanan bir üçüncü taraf kitaplığı veya yerel dilinizin standartları yerine Win API adlandırma standartlarına uygun olabilecek birlikte çalışma kodu gibi değiştirmek istemezsiniz. Sonuç olarak, kodunuza cruft ekleyerek aracınıza kodunuzdaki cruft'ı yok saymasını söylersiniz.

Her SQL enjeksiyon güvenlik açığı, bir kodlama standardıyla önlenebilecek bir kusurdur. SQL enjeksiyon güvenlik açıklarına ilişkin istatistikler AFAIK olarak mevcuttur.

Her arabellek taşması güvenlik açığı bir kodlama standardıyla engellenmiş olabilir. Bunlara ilişkin istatistikler de muhtemelen mevcuttur.