Birincisi, bir hata bulmaya çalışırken hata ayıklama kodu (örneğin print ifadeleri gibi) ekliyorum. Ve bir kere bulduktan sonra, hata ayıklama kodunu kaldırdım (ve özellikle bu hatayı test eden bir test durumu ekle). Bunun gerçek kodu bozduğunu ve bu nedenle hata ayıklamadığım sürece orada bir yer olmadığını hissediyorum.
Bunu nasıl yapıyorsun? Hata ayıklama kodunu yerinde mi bırakıyorsunuz veya eskiyse kaldırıyor musunuz (hangisi olduğu zaman karar vermek zor olabilir)?
Yanıtlar:
Hata ayıklama yazdırma ifadeleri çıkarılmalıdır; Bununla birlikte, bir üretim probleminde hata ayıklamak için onları eklemeniz gerekiyorsa, o zaman günlük çerçevenize koymak için yeterli bilginiz olup olmadığını düşünmeniz faydalı olabilir. Parametreler, hata koşulları vb. İle ilgili bilgiler, bir sonraki hatanın ortaya çıkması üzerine daha sonra faydalı olabilir. Dinamik olarak açılmış hata ayıklama veya izleme günlüğü iletilerinin olabileceği iyi bir günlük kaydı çerçevesini kullanmak vahşi ortamda çok yararlı olabilir.
Özellikle hata ayıklama için eklenen kod, üretim yazılımından kaldırılmalıdır.
Bunun tamamen kaldırılması veya koşullu derleme bölümlerine konulması (C / C ++ / C # 'da olduğu gibi) size ve kodlama standardınıza bağlıdır.
Bunun birkaç nedeni var:
ChrisF ve Alaric'in her ikisinin de geçerli noktaları var; Onlar için +1. Kullandığım en az 5 farklı hata ayıklama kodu türünü tanımlayabilirim.
Belirli bir zamanda sistem durumuna dökmek için günlükleri kullanma.
void function(...)
{
...dump everything i know about.
}
Yürütme kontrol noktaları için günlükleri kullanma.
void function(...)
{
...got here 1
...got here 2
}
Gerçekte belirli bir koşulu doğru olmaya zorlayan, ancak normal davranışı bozan kod. Örnek:
Doğrulama kaydı - Bunu, örneğin bir algoritmanın bireysel adımlarını doğrulamak gibi, üretimde yer almaması gereken yazılımın doğruluğunu doğrulamak için kullanılabilecek ayrıntılı bir kayıt olarak sınıflandırırdım.
İşlem günlüğü - Alaric'in postasına bakınız . "İşlem günlüğü" ile neyi kastediyorum.
1, 2 ve 3 tamamen çıkmalı. 4 gibi bir şey muhtemelen şartlı olarak kodun dışında derlerdim. 5 için Alaric , günlükleri dinamik olarak kapatabilmek konusunda çok önemli bir noktaya değindi . Bu, çoğu durumda ChrisF'in ikinci kurşunundaki noktayı ele alabilir .
1)… ile 1.… (böylece Markdown biçimlendirmesi bir liste olarak alır) ve örnek kodu 8 boşluk ile girerek düzgün bir şekilde biçimlendirirseniz daha iyi olur. bir listedeki kodu).
Kodun ne yaptığına bağlı. Hata ayıklama için kullanılan bazı kodlar olduğu gibi bırakılabilir ve bazılarının kaldırılması gerekir.
Bir yöntemde parametrelerin uygunluğunu doğrulayan kod, kod düzgün çalıştığında her zaman kullanışlı değildir, ancak genellikle kodun doğru çalışmaya devam ettiğinden emin olmak için saklanır.
Bazen kodda hata ayıklamayı kolaylaştırmak için farklı bir kod yazarsınız, örneğin bir değeri hesaplamak ve yerel bir değişkene koymak ve ardından bir sonraki satırda değişkeni kullanmak; kod aracılığıyla. Hesaplanan değeri doğrudan kullanmak için kodu yeniden yazabilirsiniz, ancak yerel değişkeni kullanmanın maliyeti o kadar küçüktür (eğer varsa), kodu yeniden yazmak için çok az neden vardır. Ayrıca, bir kez test ettikten sonra kodu değiştirmeden bırakmanın bir anlamı vardır, değiştirirken her zaman bir hataya neden olma riski her zaman küçüktür.
Yalnızca belirli bir hatayı bulmak için eklediğiniz kod, hatayı bulduktan sonra genellikle kaldırılabilir.
Bir zamanlar çok fazla hata ayıklama kodu kullanırdım. Neredeyse tamamen Windows’u hedefliyordum, bu yüzden daha fazla hecelemeyi hatırlayamadığım çok sayıda hata ayıklama dizgisi çıktı işlevi vardı, bu yüzden izlemeyi belirli bir programla yakalayabiliyordum.
Bazı hata ayıklama kodları, aramaların iç içe geçmesi için tasarlanan belirli şeyler yerinde kaldı. Ancak, hata ayıklama dizisi olayı çoğunlukla bir üretim sisteminde görünmez olsa da, tümü hala koşullu derleme altında yapıldı.
Gerçek şu ki, tüm bu hata ayıklama kodunun, ideal olarak farklı bir yolla ele alınan bir şey için çok çaba gösterdiği, elbette bir hata ayıklayıcı kullanarak. O zamanlar, Borland C ++ hata ayıklayıcısından o kadar etkilenmedim. Araçlar oradaydı, ancak çok sık sık yanıltıcı sonuçlar verdiler ve IDE olmayan hata ayıklayıcısını kullanmak (genellikle gerekli) kısayol tuşlarını ezberlemek anlamına geliyordu;
Daha kötü bulduğum tek hata ayıklama deneyimi GDB komut satırı.
Her gün kullandığınız araçlarda uzman olmak elbette önemlidir - ancak hata ayıklama gerçekten her gün yaptığınız bir şey olmamalıdır. Hata ayıklayıcısını çok sık kullanırsanız düzinelerce komut ve / veya klavye kısayolu öğrenmekte sorun yok, bu bana biraz kırmızı bayrak gibi geliyor.
Visual Studio 7'de çalıştığım zaman hata ayıklamanın çok pratik ve etkili olabileceği açıktı. Hata ayıklama işleminizi Visual Studio'da yapabiliyorsanız (dahil hızlı sürümleri), hata ayıklama çok kolaydır. Hiç şüphesiz doğru GUI / IDE ön ucunu bulabilirseniz, GDB de kolay ve etkilidir, ancak henüz bu aramayı yapmadım.
Birim testi için söylenecek bir şey var, gcov kullanarak kapsama analizi. Kütüphanelerinizin davranışında olduğunuzdan emin olduğunuzda, hata ayıklama işleminiz ne kadar derin olursa olsun - ve hata ayıklayıcısını en başta ne kadar sık ihtiyaç duyarsanız. Birim testleri yazmak, çoğu gün yapmanız gereken oldukça makul bir şeydir.
Beklenmedik şekilde önemli bir araç = cmake, diğer şeylerin yanı sıra GCC ve VC ++ için bina arasında kolayca geçiş yapmamı sağlayan bir oluşturma aracı. Böylece birim test ve gcov tabanlı kapsama alanımı GCC kullanarak yapabilirim, ancak hata ayıklayıcıyı kullanmak için kolayca VC ++ 'ya geçiş yapabilirim.
Benim üstesinden geldim: Hata ayıklama kodu, söz konusu kodun içindeki bir hatayı öldürmek için kullanılır. Genelde tamamen kaldırırım. Hata ayıklama kodu, dış kuvvetlerden kaynaklanan bir hatayı öldürmek için kullanılır, ben genellikle yorum yaparım.
Hata ünite testinden veya dahili ise, hata ayıklama kodu tamamen kaldırılabilir. Ancak hata üretimden geliyorsa, hata ayıklama kodu derleme etiketlerinin içinde daha iyi olur. Derleme etiketlerinin içine koymak, diğer geliştiricilerin bu kodun yalnızca hata ayıklama amacıyla olduğunu anlamalarına yardımcı olacaktır.
TDD'yi kullanın , böylece test kodunuz daima korunduğu bir yere sahiptir.