Ölü kod yazmak faydalı mı?

Ölü kod yazmayı faydalı buluyor musunuz?

Bazıları "Eğer bir işlem yapmak için 2 mantığınız varsa, o zaman diğer mantık kodunu yorum yapmak veya kodu kaldırmak yerine, işlemi etkilemeyeceği için ölü kod haline getirin."

Misal:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

Bu doğru mu?

Genellikle ölü kodlar yazmam, bunun yerine sadece ikinci mantığı kaldırırım.

IMO, anlamsızdan daha kötü.

Zaman kaybına ek olarak, size (veya bir sonraki adama), değiştirirseniz çalışacak bazı kodlarınız olduğu yanılsamasını trueverir false. Test etmedikçe bu sadece bir yanılsamadır.

Ve tabii ki, kodun okunmasını zorlaştıran karmaşıklıktır.

Herhangi bir tür SCM kullanırsanız ölü kod nadiren kullanışlıdır. Bunun yerine silmelisiniz ve mantık 2 kodunu görmeniz gerekiyorsa SCM deposundan alırsınız.

Düzenle:

Eğer ölü kodunuz varsa ve kodun diğer bölümlerini saklıyorsanız, ölü kodu açabilecek bazı kodların kullanımını deneyebilirsiniz. Eğer bir başkası bakımını yapıyorsa, aslında ölü kodunu bilmiyor olabilirler ve yapsalar bile, kesinlikle neden hala orada olduğunu bilemezler.

Daha sonra, bir yöntemin "canlı" kod tarafından kullanılmadığı, ancak yalnızca ölü kod tarafından kullanıldığı için silinebileceğini düşünüyorsanız, ölü kodunuzu değiştirmeniz (ve büyük olasılıkla kırmanız) veya diğer yöntemi ölü kodun kendisi yapmanız gerekir.

Sonunda kesinlikle bir tür bakım cehennemi elde edersiniz.

Bu nedenle, en iyi kod silinir, çünkü yanlış sonuçlar üretemez veya dikkat dağıtıcıları engelleyemez. :)

Hayır, bu kötü, çünkü kodunuzu toplar ve sürdürülebilirliği azaltır.

Genellikle, alternatif "mantıklardan" birini tercih etmenin açık bir nedeni vardır. Bu sebep (ve reddedilen bir alternatifin varlığı) bir kod yorumunda belgelenmelidir. Nedenin geçersiz hale gelmesi olası olmayan bir durumda, alternatif kod depo geçmişinden (daha önce tercih edilen, uygulanan çözümse) alınabilir veya tam güncel bilgi ve gereksinimler kullanılarak (sadece bir belirsizse) etilip uygulanabilir Fikir).

Çalışmayı etkilemez, ancak bakımı etkiler. Bakımı kolaylaştırmak için kodu olabildiğince düzenli tutmak istiyorsunuz.

Yaptıklarınızla dürüstçe kafam karıştı.

Azalan önceliğe göre:

1. Bir yerde kod değişikliklerinin kaydını tutmalısınız, böylece yeni kod çalışmazsa, bunları karşılaştırabilirsiniz. Bu her zaman kaynak kontrolünde olmalıdır. Bunu zaten yaptığınızı varsayıyorum. Değilse, bazı kaynak kontrol formunu elde etmek için elinizden geleni yapın. Kesinlikle olmadan yapmak zorundaysanız (ve hayatımda bunun iyi bir fikir olduğu bir durumu hiç duymadım), en azından kaynağın durumunu düzenli olarak erişilebilir hale getirin.

2. # 1 yaptığınızı varsayarsak, gerekirse ölü kodu kurtarabilirsiniz, canlı kodda uzun süre saklamayın. Sadece kafa karıştırıcı olacak, hiçbir değer için ekstra karmaşıklık katacak, bakım gerektirecek, canlı kodla senkronizasyondan çıkacak ve gelecekte insanları yanlış yönlendirecek, vb.

3. Bununla birlikte, iki kod yolu arasındaki bir derleme zamanı anahtarının makul olduğu belirli durumlar vardır. Yeni kodu geliştirirken ve hemen sonrasında, her ikisine de sahip olmak uygun olabilir, böylece kolayca geçiş yapabilirsiniz. Geri dönmeniz veya harici bir yapılandırma seçeneği eklemeniz gerekiyorsa, sabite dayalı bir if bu makul bir yükseltme yolu sağlar. Yani, birçok şey gibi - belirli bir sorunu çözüyorsa, yapın. Değilse, kaçının.

İnsanların bunu çok fazla yaptıklarını varsaymamın nedeni şudur: şüphe duymaktan (çoğu zaman doğru) insanların bir sorun olduğunda kaynak kontrol geçmişini gerçekten okuyacağı; korkmak yeni kod işe yaramaz ve kolay bir tersine çevirme seçeneği isteyen. İkinizi de yerine getirmeye çalışmak için bir uzlaşma, "Tarih hesaplandı ... tarihinde (Tarih). Herhangi bir sorun varsa, kaynak kontrolündeki eski sürüme bakın" veya benzeri bir yorum koymak olabilir.

Hayır, yararlı değil. Bu elseblok hiçbir amaca hizmet etmiyor. Hangi uygulamayı kullanacağınızdan emin değilseniz, yorum yapın, ayrı sınıflar oluşturun veya başka bir yere kaydedin. Ayrıca, çoğunlukla kaynak dosyalarınızın yerel veya uzak bir geçmişine sahipsiniz veya en azından sahip olmalısınız.

Koşul derleme zamanı sabitine bağlıysa, ölü kod derleyici tarafından kaldırılmalıdır, bu yüzden teknik olarak tutmak için zarar vermez. Ancak bu kodun okunabilirliğini geliştirdiği için yorum yapmayı tercih ederim.

İki kod alternatifi arasında hızlı bir şekilde geçiş yapmak istiyorsanız, aşağıdaki uygun yorum yapısını kullanabilirsiniz:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

/ilk yorum satırında yalnızca ilkini kaldırırsanız şu olur:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

Bununla /kodda bir tane ekleyerek veya kaldırarak alternatifler arasında geçiş yapabilirsiniz .

Bu başlangıçta biraz garip görünebilir, ancak alıştıktan sonra onu bir çeşit desen olarak kolayca tanıyacaksınız.

Bunu bile zincirleyebilir ve böylece tek bir karakterle aynı anda birden fazla bloğu değiştirebilirsiniz:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

Bu şekilde kullanmam ama işe yarıyor.

Eski kodun ve değiştirildiği gerçeği, gelecekteki programcıların karşı sezgisel bir şey hakkında uyarılması için gerçekten kaynak kodda kalması gereken bazı nadir durumlar vardır. Bu durumda, neden hala orada olduğunu ve neler olduğunu açıklayan bir tür yoruma da ihtiyaç vardır.

Her zaman olduğu gibi, bakımı kolay programlar yazmak, sadece zor ve hızlı kurallara uymakla kalmayıp, işleri daha net hale getirmektir. Eğer ölü kodu bırakmak, neler olup bittiğini anlamayı kolaylaştırıyorsa, bırakın. Değilse, çıkarın.

Derleyici tarafından yoksayılır. Ancak sana katılıyorum ve sadece else ifadesini kaldıracağım. Sürüm kontrolünü kullandığınızı varsayarsak, dosyanın geçmişini görüntüleyerek eski kodu görebilirsiniz.

Bu muhtemelen kişisel bir fikirdir, ancak bir kod parçasını korurken dikkat dağıtıcı ölü kod buluyorum. Herhangi bir görev için, bunu gerçekleştirmek için her zaman birden fazla yolunuz vardır, bu yüzden birini seçmeniz gerekir. Araştırmanızı yapın, algoritmaları değerlendirin ve birini seçin. Bundan sonra, kodun içinde alternatif yöntemler içermesi gerekmez.

Çok güçlü iki yarışmacı varsa, alternatif hakkında küçük bir not yazın ve bunu bir proje wiki'sine veya proje belgelerini içeren başka bir yere yapıştırın. İsterseniz, bu belgeye atıfta bulunan ve neden okumak istediğinizi açıklayan tek satırlık bir yorum ekleyebilirsiniz.

Hemen ölü kod yazmayı faydalı bulduğum bir durumu düşünemiyorum. Alternatif algoritmalar varsa, o zaman:

• ya en faydalı olanı tutar ve diğerini ortadan kaldırırsınız,
• veya algoritmalar farklı koşullara uygulanabilir ve ardından her ikisini de tutarsınız ve koşullu ilk algoritmayı kullandığınızda koşulları tanımlar.

Her iki durumda da, hiçbir ölü kod ile sonuçlanır.

Ölü kodunuzu silmez veya yorum yapmazsanız, derleyici hatalarını önlemek için bu kodu korumanız gerekir. Artık zaman. SCM'niz varsa silin.

HAYIR

Bazı programcılar bu stili yorumlara alternatif olarak kullanır ve zarif bulurlar.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

Basit cevap basit bir hayır. Ölü kod karışıklığı ve hataların ortaya çıkmasını sağlar. Kod içine bir karakter yazdığınızda bir risk söz konusudur. Yani gerekenden fazlasını eklemeyin.

Bir kez benzer bir şey yazmak zorunda kaldım bir derleyici hata için bir çalışma olarak, hatta derleyici satıcı tarafından bu işi kullanmak için tavsiye edilmiştir.

Yazdığınız ölü kodu test ediyor musunuz? Muhtemelen iyi olduğunu onaylamak için herhangi bir şey var mı? Değilse, ondan kurtulun.

Gelecekteki kod değişiklikleri için, ölü kodun hala çalıştığını doğrulayacak mısınız? Değilse, ondan kurtulun.

Kullanılmasa bile programlarınızda kötü kod istemezsiniz. Orada olması, kullanılabileceğini gösterir. Her ikisini de kullanmazsanız, genellikle iki kod sürümünü korumak istemezsiniz, çünkü bu ekstra bir iştir ve anlamsız olduğu için çoğu insan ölü kodda iyi bir iş yapmaz.

Yorumlanmış kodu (veya C veya C ++, #ifdefdüzenlenmiş kodu) tutmak için nedenler olabilir , ancak buna neden hala orada olduğu ve hangi amaca hizmet ettiği ile ilgili yorumlar eşlik etmelidir.

Java'da, erişilemeyen kod nedeniyle aşağıdakilerin bile derlenmeyeceğini unutmayın:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

İdeal olarak, kodunuzla ilgili bir sorun varsa, üretime geçmesine ve kullanıcılarınız tarafından bulunmasına izin vermek yerine, kodu mümkün olduğunca erken bulmak istersiniz.

Derleyiciniz tarafından bir hata sınıfı bulunabiliyorsa, derleyicinin bulmasına izin verin. Birinin tanımladığınız şekilde ölü kod yazarak yaptığı IMHO, derleyici hatasını atlatmaya çalışıyor ve çalışma zamanında ortaya çıkmasına neden olabilecek sorunlara izin veriyor.

Ölü koda ulaşılamayacağını, bu yüzden sorunlara neden olamayacağını iddia edebilirsiniz, ancak yorum, destekleme ve girintide bir şeyler ters gidebilir.

İnsanların eski mantığı yorumlamalarının nedeni, kodda büyük değişiklikler yapmaktan korkmalarıdır. Ve aslında, bir hafta sonra eski kodun gerçekten doğru olduğunu ve şimdi sıfırdan yazmak zorunda olduğunuzu fark etmek bir orospu. Ama kaynak kontrolü bunun için. Eğer bir mantığı değiştirmeye karar verirseniz, biraz çalışan mevcut kodu kaybetmekten korkmayın. Çıkarın ve SVN / Git / TFS'nizin sizin için sürüm oluşturmasına dikkat edin.

Durum böyle değilse ve YAGNI veya DRY'yi umursamadığınız için bir şey yapmak için iki farklı mantık parçası ürettiyseniz, o zaman insanların kullanabileceği bir yere koyduğunuzdan emin olun. Belki bir strateji örüntüsü koyarsanız, isterseniz. Sadece bu "eğer .. else" şeyleri yapma, kötü tasarım ve sürdürmek için bir acı. Gerçekten bazı kodların var olma hakkına sahip olduğunu düşünüyorsanız, onu kullanmayı mümkün kıldığınızdan emin olun.

Buna bir başka bakış, temelde çoğu profesyonel programcının kodun boyutunun düşman olduğunu kabul etmesidir. Bu blog yazılarına bir göz atın: En iyi kod hiç kod değil Kod At Steve Yegge tarafından en kötü düşmanı Jeff Atwood, çok daha fazlasını bulabilirsiniz.

İnsanlar, kodlarını kısa tutmak ve kod tabanının çok büyük hale gelmesini önlemek için, çoğu zaman performanstan (çok fazla önemli olmayan yerlerde) bile olsa çok şey yapıyorlar. Yani, 100 satırlık ölü kodun iyi bir şey olabileceğini düşünüyor musunuz?

Bunun yararlı olduğunu gördüğüm tek yer, bir şeyi hızlı bir şekilde devre dışı bırakmak ve test / dolgu doldurmak istediğiniz durumlardır (Programın A, B, C adımlarını uyguladığını söyle - hepsi uzun zaman alıyor. Dolgu sırasında B ve C'yi devre dışı bırakmayı seçebilirsiniz. gerekli olmadığını biliyorsanız zaman hızlandırmak için).
Ama gerçek şu ki, her durumda bu çok acayip. Dolgu kodunuz için uzun süreli bir kullanım görürseniz, kodunuzu, bu tür saldırıları kullanmak yerine bir seçim seçmek için config'i kullanacak şekilde yazmalısınız.
Başlıca hızlı kuralım, bu tür kodları asla kontrol etmemem. Bir check-in / sürüm kontrolüne ihtiyacınız varsa, bu kısa süre sonra buna geri dönebileceğiniz anlamına gelir ve değişen gereksinimler ışığında her zaman kötü bir şeydir.

Aslında, "ölü" koduna sahip olmanın yararlı bir yolu vardır: programınızın büyük bir istisna atmasını istediğinizde, daha önce olmaması gereken bir şeye ulaştı. Bu bir derleyici hatası veya satırın üstündeki biri kullandığınız testteki mantığı değiştirip vidaladıysa. Her iki durumda da, "başkası" havai fişek gönderir. Bu durumda, yayınlanmak üzere ifdef istiyorsanız.

Hata mesajının "Panik:% s dosyasında% d satırında olmamamız gerekiyor" gibi bir durumu belirtmesi çok önemlidir ...