it-swarm-tr.com

Yorum kodu gerçekten her zaman kötü mü?

Pratikte okuduğum kod kalitesindeki her metin, kodun yorumlanmasının kötü bir şey olduğunu kabul eder. Genel örnek, birisinin bir kod satırını değiştirmesi ve eski satırı orada bir yorum olarak bırakması, görünüşte kodu daha sonra okuyan insanları karıştırmasıdır. Tabii ki, bu kötü bir şey.

Ama sık sık kendimi başka bir durumda yorumlanmış kod bırakarak buluyorum: Bir hesaplama geometrisi veya görüntü işleme algoritması yazıyorum. Bu tür bir kodu anlamak ve içindeki olası hataları bulmak için, ara sonuçları görüntülemek genellikle çok yararlıdır (örneğin, ekrana bir dizi nokta çizin veya bir bitmap dosyası kaydedin). Hata ayıklayıcıdaki bu değerlere bakmak genellikle bir sayı duvarına (koordinatlar, ham piksel değerleri) bakmak anlamına gelir. Çok yardımcı değil. Her seferinde bir hata ayıklayıcı görselleştiricisi yazmak aşırıya kaçar. Görselleştirme kodunu nihai üründe bırakmak istemiyorum (performansı bozuyor ve genellikle sadece son kullanıcıyı karıştırıyor), ama ben de kaybetmek istemiyorum. C++ 'da #ifdef koşullu olarak bu kodu derlemek için, ama bu arasında çok fark görmüyorum:

/* // Debug Visualization: draw set of found interest points
for (int i=0; i<count; i++)
    DrawBox(pts[i].X, pts[i].Y, 5,5);
*/

ve bu:

#ifdef DEBUG_VISUALIZATION_DRAW_INTEREST_POINTS
for (int i=0; i<count; i++)
    DrawBox(pts[i].X, pts[i].Y, 5,5);
#endif

Yani, çoğu zaman, görselleştirme kodunu yorumda bırakıyorum, görselleştirilen şeyi söyleyen bir yorumla. Bir yıl sonra kodu okuduğumda, genellikle görselleştirme kodunu açığa çıkarabilirim ve kelimenin tam anlamıyla "neler olduğunu görebilirim".

Bu konuda kötü hissetmeli miyim? Neden? Üstün bir çözüm var mı?

Güncelleme: S. Lott bir yorumda soruyor

Bir şekilde yorumlanmış tüm kodları, hata ayıklamayı ve anlamsız, eski kodu içerecek şekilde "genelleştiriyor musunuz?" Neden aşırı genelleşmiş bir sonuç çıkarıyorsunuz?

Geçenlerde Robert Martins "Temiz Kod" okudum:

Birkaç uygulama yorum kodu kadar tuhaftır. Bunu yapma !.

Kitaptaki paragrafa tekrar baktım (s. 68), yeterlilik yok, kodun yorumlanmasının farklı nedenleri arasında ayrım yapılmadı. Bu yüzden, bu kuralın aşırı genelleme (ya da kitabı yanlış anlamış mıyım) ya da yaptığım şeyin kötü uygulama olup olmadığını merak ettim, bir nedenden dolayı bilmiyordum.

53
nikie

# İfdef'in yorum yapmak yerine faydası, (büyük projelerde) tanımları bir make veya config dosyasında listeleyebilmenizdir - ve bu nedenle manuel olarak bir rahatsızlık verici şeylere gitmeniz, derlemeniz ve ardından yeniden -çoğu yerde varsa onları tavsiye. Bunun dezavantajı, projenin DEFINE'lerini değiştirmenin sadece değiştirilen dosyaları değil, her şeyi yeniden oluşturmak anlamına gelmesidir.

Gerçi ... Bence "yorum kodu kötü bir şeydir" gerçekten ölü kod insanlar sadece ne olursa olsun silmek istemiyor anlamına gelir Sebep (belki de geçirdikleri bir şeyi atma korkusu?). Bu sizin için durumunuzla ilgili değil.

58
TZHX

Yorumlanırsa, çürük olabilir: aniden tekrar ihtiyacınız olduğuna karar verdiğinizde, artık derlenmediğini veya bu arada değişen diğer şeylere uyması için yeniden yazılması gerektiğini fark edersiniz.

Kodu içinde bırakırsanız, ancak derleyici gerekli değilse optimize edebilecek şekilde, kodu güncel tutmanızdan faydalanırsınız ve eklenen ikili dosyaya maruz kalmamanız boyut veya çalışma zamanı performansı.

Örneğin, C'de bu çürüme riski altındadır:

/*
doSomeDebugStuff();
*/

Ve bu da:

#if 0
doSomeDebugStuff();
#endif

Ancak bu iyidir, çünkü derleyici tarafından her zaman geçerliliği kontrol edilir, ancak optimize edilmesi muhtemeldir:

if (0)
{
  doSomeDebugStuff();
}

Düzenleme: diğerleri işaret gibi, test için 0 Yerine anlamlı bir sembol kullanarak daha da iyidir.

25
Graham Borland
// The problem with commented out code is that it can hide what you're actually
// trying to say in a wall of text.  Syntax highlighting may help, but you're 
// still left with this huge ginormous wall of text in front of you, searching
// through it for what the actual answer is. You'd think that mentally it'd be 
// really easy to disregard the comments, but in actual usage, it's a lot harder
// than a one Word answer that can tell you what you're looking for. It's tough.
/* Sometimes they'll even through you off with different comments. */ Yes.
// It's really tough to deal with people that don't like to use source control, 
// that would rather comment lines and lines of code instead of deleting the 
// code and checking in revision.  Cue irrelevant paragraph about the reason why 
// I wrote this instead of just deleting the entire block and replacing it 
// with my intention. Maybe I was hedging my bets? Cue misspelled wrod.  
18
George Stocker

Eski yorum ve sadece bir hata ayıklama yapısı (veya koşullu derlenmiş başka bir "özel" yapı) kullanılan kod arasında bir ayrım yapılması gerektiğini düşünüyorum. İkincisi ortak bir uygulamadır ve hiçbir şey yanlış değildir.

Birincisi, bir kaynak tabanında bulunmamalıdır, çünkü sürüm kontrol sistemi eski şeyleri takip eder, geri almak istediğinizde.

15
Alex Budovski

Kodlamada hemen hemen hiç "her zaman" yoktur :) Bir kılavuzun arkasındaki nedenler hakkında yeterince bilginiz varsa ve bunu kırmak için gerçekten iyi bir nedeniniz varsa, bunu yapın.

Örneğin, "kamikaze-refactoring" yaptığımda kod yazıyorum ve bir şeyler geri eklemek veya eski kodun bir süre nasıl çalıştığını hatırlamak için görsel bir hatırlatma gerekiyor. Bu gibi durumlarda daha sonra yorumları silmeniz çok önemlidir, aksi takdirde kodunuzu karmaşık hale getirirler.

11
Homde

Bazen kodları yorumlarınıza göstermek için nasıl kullanılır bir sınıf koyarsınız - bu, eskiden kullanılan yorum kodundan çok farklıdır.

8
Ian

Kod değerlendirmeleri bir sürü yapmak ve yorum ne olursa olsun kodu için gerçek bir bahane buluyorum. Yorumlanan kodu hata ayıklama amacıyla kullanıyorsanız, serbest bırakma modunda devre dışı bırakılan veya izleme düzeylerine (bir sürümde izleyebilmek her zaman iyidir) bir izleme mekanizması oluşturabilir veya bir hata ayıklayıcı kullanabilirsiniz.

Yorumlanan kod kötüdür, çünkü diğer insanlar kodu okuduğunda - özellikle orijinal yazar tatilde değilken bir hatayı düzeltmeye çalıştığınızda - özellikle hata yanlışsa, kodu okumanın çok kafa karıştırıcı olması satırın başına // yerleştirildi .../* kullanarak bile, orada olması gereken bir şey hakkında yanlışlıkla yorum yapabilirsiniz - ya da değil.

Kodunuzu temiz ve daha okunaklı tutmak için, önemli olabilecek ya da olmayabilecek kodu okumak zorunda kalmadan programları okumak zaten zor olan yorumlanmış kodu kaldırın.

3
AndersK

Evet öyle.

Üretim sürümünüzde istemediğiniz hata ayıklama kodunuz olsa bile, yorum yapmamalısınız. #ifdef 'Leri kullanmak daha iyidir çünkü hata ayıklamayı #define Makrosuyla veya ayrı bir yapı yapılandırmasına sahip olarak kolayca açıp kapatabilirsiniz. Bu kesinlikle koda gitmek zorunda ve hata ayıklama kodunun her bloğunu manuel olarak yorumlamak/uncommenting yener.

Ve bazı hata ayıklama bloklarını açma esnekliğine ihtiyacınız varsa, ancak diğerlerini değil, hata ayıklama bloklarını "hata ayıklama düzeyleri" olarak gruplandırmalısınız.

Daha iyi bir çözüm, ön işlemciyi hiç kullanmamak ve sabitler ve if-ifadeleri gibi yerel dil özelliklerini kullanmak olacaktır. Yani yerine

#define DEBUG0
#ifdef DEBUG0
  // debugging code
#endif

alabilirsin

const bool DEBUG0 = true;
if(DEBUG0)
{
  // debugging code
}

Bunu yapmanın avantajı, ön işlemciyi kullanmaya göre, hata ayıklama kodunuzun her zaman derleyici tarafından kontrol edilmesidir. Bu, çevresindeki kodu değiştirdiğinizde çürümesi olasılığını azaltır.

Boole bayrağını yanlış yaparsanız herhangi bir performans isabetine maruz kalmazsınız, çünkü modern derleyiciler erişilemez kodu optimize eder. En kötüsü, derleyici hakkında uyarı alabilirsiniz.

2
Dima

Yaptığın şeyin dışarıda ve dışarıda kötü olduğunu düşünmüyorum ama en azından ne yaptığını, neden ve nasıl ve ne zaman kullanıldığını açıklamak için onunla bazı gerçek yorumların olması gerektiğini düşünüyorum. o.

Şahsen ben normalde bu tür bir şey IF DebugMode = TRUE türü çaba bir tür söz konusu kod etrafında koymak ve bir komut satırı/başlangıç ​​parametresi olarak ayarlayın. Bu yüzden kodun orada olduğunu ve örneğinizde nasıl ayarlanacağını görmeyi kolaylaştıran benim için bundan kaçınmak istediğiniz küçük karşılaştırmayla bile performans sorunları olabilir.

Bu yüzden muhtemelen ne yaptığınızı yanlış ve yanlıştan ziyade gerekli bir kötülük olarak görüyorum. Eğer onu düzene sokmak için bir yol bulabilirseniz, o zaman tabii ki yapın ama bu konuda kendinizi dövmezdim.

1
Jon Hopkins

Kod yorumladı nedenlerinden biri, bir kod kokusu olarak kabul edilir ya o koymak programcı kendi kaynak kontrol anlamıyor ya da herhangi bir kullanmıyor olduğunu gösterir olduğunu düşünüyorum. Her ikisi de yaptıkları diğer birçok şey hakkında daha fazla şüphe uyandırdı.

Bunun meşru bir sebebi varsa ve bunun neden bulunabileceğinin meşru bir nedeni olduğuna dair bir açıklama bırakmış olabilirsiniz. Genellikle kötü haber olarak kabul edilen çoğu şey sağ elinde de yararlı bir araç olabilir. Sorun şu ki, bu eller kendilerine sahip olduğunu düşünen insanlardan daha nadirdir.

0
glenatron

Programcıların zihinlerinin o sırada nasıl çalıştığına dair bir geçmiş sağlamaya yardımcı olur. Ancak, her yerde bulunan kaynak kontrolünün bu günlerinde, son bir kesimde bırakmak için bir neden yok - önceki sürümler, buna başvurmanız gerektiğinde eski kodu içerecektir.

0
5arx

Burada mutlak olduğunu düşünmüyorum. Bazen sadece küçük bir snippet, özellikle kısa bir süre sonra tekrar uncomment makul bir şans varsa yorum kodu bırakın. Temelde, bu kod parçacıklarını gerçek kodun okunabilirliğini bozmadıkları ve her yerde çoğalmadıkları sürece terk ediyorum.

Ne kesinlikle reddetmek yorum kodu tam yöntemler olduğunu. Evet, daha önce gördüm: WTF. Kaynak revizyon cennette dinlenebilirler ;-)

0
Andres F.