Derleyici Uyarıları

Birçok derleyici, programcıları olası çalışma zamanı, mantık ve performans hataları hakkında uyarmak için uyarı mesajlarına sahiptir, çoğu zaman bunları hızlı bir şekilde düzeltirsiniz, ancak düzeltilemez uyarılar ne olacak?

Düzeltilemez uyarılarla nasıl başa çıkıyorsunuz? Kodun bir kısmını yeniden mi yazıyorsunuz, yoksa "uzun, korsansız bir şekilde" mi yeniden yazıyor veya uyarıları birlikte devre dışı mı bırakıyorsunuz? En iyi uygulama ne olmalı?

Başka birinin kodunu düzenliyorsanız ve kodunda uyarılar varsa ne olur?

İşte iyi bir örnek: jQuery'de Mozilla sınıfı bir tarayıcı algılandığında çok sayıda JavaScript uyarısı var, jQ geliştiricileri neden bunları düzeltmiyor? JQuery'ye katkıda bulunursanız, bunları düzeltir misiniz?

Bazı uyarıları görmezden gelmek genellikle güvenlidir, ancak bunu yaparsanız zamanla o gün gelene kadar çoğalırlar.

Uyarıları hemen düzeltin ( bağlamınızla hiçbir zaman alakalı olmadığını düşünüyorsanız, bireysel kuralların devre dışı bırakılmasını içerebilir ).

Bence kendinize karşı katı olmalısınız. Derleyici, dilde toplam uzman tarafından yazılmıştır. Bir şeylerin biraz zor olduğunu bildiriyorlarsa (kod kokusunu düşünün) kod gözden geçirilmelidir.

Hatasız ve uyarı olmadan derlenen kod yazmak tamamen mümkündür.

C ve C ++ 'da yazarken, derleyici için bir şeylerin ne zaman mantıklı olmadığını bilmek istediğim için yapabileceğim en katı ayarları etkinleştirirdim. Ben döküm ve dönüş değerleri kontrol bittiğinde ben kod yapabilirim kadar doğru olduğu için mutlu olurdu.

Bazen uyarıları söyleyen birinden kod alırdım. Kaynağı kontrol etmek, C'de iyi programlama uygulamaları olan şeyleri görmezden geldiğini ve kodlarını kırılgan hale getirdiğini gösterdi.

Bu nedenle, katılığı etkinleştirmek ve bir şeyleri düzeltmek için zaman ayırmak için iyi nedenler olduğunu düşünüyorum. Aksi takdirde özensizdir. Uyarıları kapatan bir iş arkadaşım olsaydı, onlarla biraz zaman geçirirdim ve bunun neden gerçekten kötü bir şey olduğunu açıklayan yönetici.

Herhangi bir uyarıyı düzeltirim. Onları görmezden gelir ve birikmelerine izin verirseniz, önemli bir şeyi kaçırmış olabilirsiniz.

Genellikle derleyiciyi sessiz hale getirmeye çabalamalısınız, böylece yeni uyarılar daha fazlasını gösterir. Bu uyarılar hafif hataları gösterebilir ve uygun şekilde ele alınmalıdır.

Diğer insanların kodunu düzeltmekle ilgili olarak, bu hem işyeri kültürünüze hem de kodun mevcut durumuna bağlıdır. Tam bir yeniden test döngüsünü tetiklerse, sadece test aşamasındaki veya üretimdeki kod için olduğu gibi kodu değiştiremezsiniz.

Patronunuza sorun ve ona göre hareket edin.

Bir derleyici uyarısı her gördüğünüzde, durup müşterinin sitesinde yüzünüzde patlamayı bekleyen bir sorun mu yoksa göz ardı edebileceğiniz bir şey mi olduğunu düşünmeniz gerekir. Daha da kötüsü, BUGÜN görmezden gelebileceğiniz şeyler, görünüşte ilgisiz bir kod değişikliğinden sonra birkaç yıl içinde müşterinin sitesinde patlayacak şeyler olabilir.

Uyarıları düzeltin. Dönemi. Bu, ya da her birini, bir risk olmadığını kanıtlamak için gerekli sayıda açıklama sayfasıyla, en sevdiğiniz kız arkadaşınızda (veya porno saklamasında) imzalı bir satış siparişinin eşlik ettiği kanıtlanır. Bir risk OLDU.

Genellikle, yapınızın uyarı gerektirmemesini istersiniz. Uyarılar bir nedenden dolayı vardır ve genellikle çok gerçek sorunlara işaret ederler. Derleyici uyarılarını göz ardı etme alışkanlığına girerseniz, sonunda yapınızın bir tonu olacaktır ve şirketinize pahalıya mal olacak felaket bir sorunun neden olduğu uyarıyı kaçırırsınız. Öte yandan, programınız normalde uyarı olmadan derleniyorsa, her yeni uyarı hemen fark edilir ve hızlı bir şekilde adreslenebilir.

Bunu söyledikten sonra, bazen derleyiciler çok mantıklı olmayan ve kolayca düzeltilemeyen uyarılara sahip olabilirler. TI DSP'leri için bir geliştirme ortamı olan TI CodeComposer ile her gün bu durumla karşılaşıyorum. Visual Studio altında hiçbir uyarı ile derler, ancak standart T ++ desteği daha iyi olabilir çünkü CodeComposer, garip uyarılarla sonuçlanan C ++ kodu var. Neyse ki, CodeComposer belirli uyarıları ayrı ayrı devre dışı bırakmanıza izin verir, bu da uyarıyı üreten kodu düzeltmenin bir yolu olmadığında yapmamız gereken şeydir.

Benim durumumda uyarılar PyLint aracından geliyor ve yorumlara özel metin ekleyerek belirli bir satırdaki bir uyarıyı devre dışı bırakabiliyorum.

Çoğu durumda, bunu yapmam. Çoğu durumda, PyLint'in genellikle doğru olması nedeniyle PyLint'in önerilerini takip etmek için kodu değiştiririm. Bununla birlikte, hoşlanmayan şeylerde genellikle kötü bir fikir olan, ancak belirli bir bağlamda mantıklı olan yapılar. Örneğin, tüm olası istisnaları yakalayıp yakalamadığımdan şikayet ediyor. Genellikle, doğru, bu kötü bir fikir olurdu. Ancak, bazı durumlarda, kendime ayrıntıları içeren bir hata raporu göndermek gibi tüm istisnaları yakalamak istiyorum.

Yani: Hemen hemen her durumda, saldırılardan kurtulun. Kesmek gerçekten haklı olduğunda, PyLint'e iyi olduğunu söyleyen bir yorum ekleyin.

Katılığın bazı faydaları diğer cevaplarda açıkça ifade edilmemiştir:

1. Kolayca düzeltilebilir tüm uyarılar giderildiğinde, kalan önemli / ilgili uyarıların görünme olasılığı daha yüksektir.
2. İlgili uyarılar bulunursa ve zamanında (yayınlamadan önce) ele alınırsa, hatalardan kaçınılabilir ve böylece daha iyi son kullanıcı memnuniyeti elde edilir.
3. Uyarıyı çözmek genellikle daha sürdürülebilir ve daha basit bir koda yol açar (örneğin her zaman doğru olan koşulları ortadan kaldırmak)
4. Uyarı miktarı 0'a yakın olduğunda, ekipteki Sıfır Uyarı Politikası üzerinde anlaşmak kolaydır, bu da CI sisteminde otomatikleştirmek çok kolaydır.
5. Derleyici uyarılarını çözerken, program kodunun anlaşılması derinleşir, bu da uygulama hakkında faydalı bilgilere yol açabilir (örn. Diğer hataları keşfedin veya kodu nasıl geliştireceğiniz hakkında fikir edinin)
6. Derleme daha hızlı, günlük üretkenlik artar: IDE / derleyicinin yönetilmesi ve raporlanması için daha az sorunu vardır, bu nedenle derleme daha hızlıdır (bu yalnızca binlerce uyarı bağlamında geçerlidir).

Belirli uyarı türlerinde dile özgü farklılıklar vardır. Konuyla ilgili düşünmek ve tartışmak ve daha sonra tamamen yararsız hissettikleri takdirde bazı bireysel uyarıları devre dışı bırakmak önemlidir, böylece katılık elde edilebilir. Bu, kariyerim üzerine birkaç takımda başarıldı. Konuyla ilgili deneyimlerim hakkında daha fazla bilgi

Uyarılar ve hatalar, derleyicinin programcıya "yazdığınız bir şeyin mantıklı gelmediğini" söylemek için kullandığı mesajlardır - aralarındaki fark, bir uyarı ile derleyicinin programcının niyetlerini tahmin etmeye istekli olmasıdır. bir hata ile derleyici tahmin bile edemez.

Derleyici hataları ele alınacaktır ( sabit demeyeceğim ), ancak çok sık, programcılar (deneyimli olanlar bile) uyarıları yok sayar. Uyarıları dikkate almama sorunu bazen derleyicinin yanlış tahmin etmesidir ve 1000'den fazla uyarı mesajınız varsa, derleyicinin yanlış tahmin ettiğini belirten bir uyarı mesajını kaçırmak kolaydır.

Sosyolojik açıdan, birçok uyarı mesajı içeren programlar Kırık Pencereler'dir .