Kaynağınızdaki Anlamsız Kod

Bunun üst düzey kodlayıcılarından hikayeler duydum ve bir kısmını kendim gördüm. Görünüşe göre kodsuz kod yazan birkaç programcının örneği var gibi görünüyor. Gibi şeyler göreceğim:

• Hiçbir şey yapmayan yöntem veya işlev çağrıları.
• Gereksiz kontroller ayrı bir sınıf dosyasında, nesne veya yöntemde yapılır.
• if her zaman doğru olarak değerlendirilen ifadeler.
• Dönen ve hiçbir şey yapmayan konular.

Sadece birkaç isim. Bunun, programcıların kasıtlı olarak kodları kuruma kendi değerlerini arttırmak için kafa karıştırıcı hale getirmek veya sözleşmeli veya dış kaynaklı işlerde işi tekrarlamak istediğinden emin olmak istedikleri söylendi.

Benim sorum. Başka biri böyle kod gördü mü? Sonucunuz neydi, bu kodun neden oradaydı?

Herhangi biri böyle bir kod yazdıysa, nedenini paylaşır mısınız?

Kodlama başarılarını gerçekte olduklarından daha karmaşık hale getirmeye çalışan geliştiriciler duydum. Bunu kimsenin itiraf ettiğini hiç duymadım, ama kasıtlı olarak acele veya kötü uygulamalardan oluşan ve sabotajlar dışında yarattığınız kriterlerinize uyan bir kod gördüm. Kötü hizalanmış kodu çevreleyen kod, belirli bir işlevin artık kullanışlı olmadığı noktalara değiştirilmiş olabilir.

Birisinin bu karmaşıklığı yalnızca bu geliştiricinin yönetebileceği sonucuna varmadan önce bu kodu ilk elden görmesi gerekecekti. Çoğu yönetici ve diğer iş adamları bu sonuca varıyorlar çünkü herhangi bir kod anlamıyorlar ve pozisyonu yeniden doldurmak istemiyorlar.

Kodu bu şekilde görmedim ancak anlamsız görünen veya diğer nedenlerle anlamsız görünen kodu gördüm:

1. Geriye dönük uyumluluk. Bir şeyleri yapmanın çok daha iyi bir yolunu buldunuz ancak eski (ve şimdiye dek pek kullanışlı değil) API / işlevini eski tutmalısınız, çünkü dışarıdaki bazı üçüncü taraf modülleri bu API / işlevini bir şey için kullanıyor olabilir. İşlev yararlı bir şey yapmasa bile, onun olmaması bazı kodları bozabilir.

2. Savunma kodlaması. Bu koddaki kontrollerin anlamsız olduğunu biliyorsunuz, çünkü bu zaten başka bir yerde kontrol edildi. Ancak, birisi bu kodu başka bir yerde değiştirirse ve ön koşullarınızla artık eşleşmemeleri için çekleri kaldırır veya değiştirirse?

3. Organik büyüme. Büyük projelerde yıllar geçtikçe birçok şey değişiyor ve artık kullanılmayan bazı yöntemler artık ortaya çıkıyor, ancak hiç kimse bu özel yöntem kullanılıp kullanılmadığını takip etmediği için hiç kimsenin çıkardığı için rahatsız etmedi. kodlarını ve şans eseri olduğu için hepsi bu yöntemi kullanmaktan vazgeçtiler. Ya da bir zamanlar anlamı olan ancak uygulama başka yerlerde daha da kötüleşti, böylece şartlar her zaman gerçek oldu, ama kimse onu kaldırmak için zahmet etmedi.

4. Aşırı tasarımı. İnsanlar bazı şeyleri “tam da ihtiyacımız olursa olabilir” diye kodlayabilirler ve asla buna ihtiyaç duymazlar. "Çevrimdışı bir iş yapmamız gerekebilir diye bir ipliği verelim" ve sonra kimse çevrimdışı bir şey yapmayı istemez ve programcı bunu unutur ve diğer projelere (veya belki başka bir şirkete) geçer ve bu kod orada kalır sonsuza dek çünkü kimse neden orada olduğunu veya onu çıkarmanın güvenli olup olmadığını bilmiyor.

Bu yüzden, iş güvenliği konusundaki kötülükten ya da yanlış yönlendirilmiş yaklaşımdan hiç görmedim, bunun yanında yazılım geliştirmenin doğal bir sonucu olarak birçok kez gördüm.

Benim sorum. Başka biri böyle kod gördü mü? Sonucunuz neydi, bu kodun neden oradaydı?

1) Evet.

2) Gördüğüm davalarda, aşağıdakine çeşitli şekillerde koyardım:

• Programcı tecrübesizliği
• Programcı, değiştirmeye çalıştığı özellikle karmaşık ve / veya kötü uygulanmış bir tasarımı anlamadı
• Programcı bir refaktörün ortasında (örneğin) yarıda kesiliyor.
• Dikkatsizlik

Şimdi belki buna yardım ediyorum, ama benim genel yaklaşımım, parmakları işaret etmekten ve kalitesizliği sürdürmekten ziyade, bu konularla ilgili affetici / çatışmacı olmanın daha iyi olduğudur. Açıkçası, bir şeyler yapılması gereken şeyler yeterince kötüye gidebilir , ancak doğru yönde yumuşak bir dürtme genellikle yeterlidir.

Tabii ki, eğer kalite / hatalar “işi” ciddi şekilde etkileyecekse, bu kadar yanlış bir yaklaşım benimsemezsiniz. Ancak bu durumda , kapsamlı bir test prosedürü ile birlikte her şeyin zorunlu ve özenli kod incelemelerine ihtiyacınız var .

Tecrübelerime göre, insanlar kişisel standartlarını ihlal ettiği için düşük kalite kodu konusunda (“en azından kısmen)” “sıkı” olma eğilimindedir. Mükemmel olmak için (kişisel olarak) gayret etmek gayet iyi, ama kişisel standartlarınızı diğer insanlara yansıtmanız biraz mantıksız. Şeylerin sesleriyle (örneğin örneklerin doğasından), yaptığınız şey budur.

IMO, bu üretken değil ve iş arkadaşlarınızla iyi bir iş ilişkisine elverişli değil.

Bunların hepsi genellikle bir projenin yaşlanma belirtileridir.

 1. Hiçbir şey yapmayan yöntem veya işlev çağrıları. Bazı kodların olduğu gibi bırakıldığı birçok zaman vardır (umarım büyük bir kullanımdan kaldırılmış uyarıyla, ancak çoğu dilde bu uyarı olmadığından, her zaman izlenmez ...) çünkü bir noktada bazı orijinal amaç ve kimse rahatsız edici çizgiler kaldırılırsa ne olacağını bilmiyordu.

Bunu dailywtf'den hatırlıyor gibiyim:

@deprecated // he might have been crazy enough to use reflection...
boolean getTrue() {
    return false; 
}

 2. Yedekli kontrolleri ayrı bir sınıf dosyası, nesne veya yöntem ile yapın. İletişim katmanları da mükemmel değildir (hiç Efsanevi Adam Ayı okudunuz mu? Olmazsa, bilgisayarda ne yapıyorsunuz !? Git! OKUYUN!). Genellikle, bir kişi bir şey üzerinde çalışacak ve sonra projeden ayrılacak ve daha sonra garip bir böcek bulan bir sonraki adam, burada ve orayı ortadan kaldırmak için fazladan bir kontrol yapacaktır. Hata giderildiğinde, kontroller yapılmadığı için değil, eğer kırılmadıysa düzeltmeyin.

 3. Her zaman doğru olarak değerlendirilen ifadeler. Oh, bunu yaptım. Bir keresinde bir projem var, muhtemelen blok halinde 10-15 dizisine sahipti . Davranışı değiştirmek için basitçe true||ilk bloğa koydum . Daha sonra aylarca (yıl mı?) Dönüp, "Ah, vay, bu kodun imha edilmesi gerekiyordu ama asla olmadı" dedi.

 4. Dönen ve hiçbir şey yapmayan konular. Böyle bir düşüncenin hayalini kurabilirim:

1. Biliyorum! Bu iki sorunu asenkron olarak halledebilirim! Foo ve bar'da konu oluşturacağım.
2. (iki ay sonra) Huh, biliyorsun, bardaki işlevsellik biraz daha iyidir. Biraz hareket edeceğim.
3. (bir yıl sonra) Bilirsiniz, bu diğer şeyleri bardan foo'ya koymak mantıklıdır.
4. (çok, uzun yıllar sonra) "Hey, bu barkonu hiçbir şey yapıyor gibi görünmüyor, çıkarabilir miyiz?" "En iyisi, uzun yıllar oldu ..."

Ben biraz daha iyimserim. Bence indiğiniz sık sık, kod dikkatsizce yeniden yapılandırıldığında meydana gelir.

Yaşlı adamlar bana danışmanların ürettikleri kod satırı sayısına göre ödeme yaptıkları zamanı anlattılar. Böylece şaşırtıcı derecede uzun soluklu yapıları kullanarak karı maksimize ettiler .

Günümüzde her zaman adamın işi yaparken hala dili öğrendiğini varsayıyorum . Ve acelesi var.

Cevapların çoğu bu iki basit gerçeğe dayanıyor:
[1] Kod, kodun geçmişini ve
[2] Kod, kodun beklenen geleceğini yansıtıyor.

Değerli hiçbir şey yapmayan işlevler yazdım, GÜNCEL UYGULAMA ORTAMINDA, GÜNCEL ÖZELLİKLERİ verilen, ancak gelecekte gerekli olabilir.

Şu anda AT her zaman doğru olarak değerlendiren if-ifadeleri yazdım. Ama belki geçmişte yanlış olabilir.

Gereksiz kontrollere gelince, başka bir koda güvenmiyorum, kendi koduma bile güvenmiyorum. Bir modül N'nin 1 veya 2 veya 3 olmasına bağlıysa, bundan daha iyi korunmuş olduğundan emin olun, eğer değilse bilgilendirici bir şekilde çökmesini sağlayın. Modül A berbatlaştığı için Modül B'nin patlaması yasadışıdır; Modül B'nin Modül A'nın berbat olduğundan şikayet etmesi oldukça meşru. Ve önümüzdeki ay, bu parametrenin henüz yazılı olmayan Modül C'den gelebileceğini unutmayın.

Bunu birkaç kez gördüm, aslında sadece dün, patronlarımın kodunu yeni uygulamamda birleştirmem gerekiyor. Bu durumda genel bir beceri ve anlayış eksikliğine ve oldukça yetenekli bir geliştirici olduğunu düşündüğü inancına bağlı.

'Hiçbir şey yapmayan yöntem veya işlev çağrıları.' ve 'her zaman doğru olarak değerlendirilen ifadeler' kodu ile ilgili büyük bir sorundur.

Birçok rağmen şüpheli görülen bu sorunları vardır kod, kaç itiraf ediyorum yazma aynı. Her şeye rağmen, gördüğünüz şey biriken yazılım çürüklüğü - birisi gerçekten işe yaramayan bir şey ekliyor, bir sonraki bakımcı, ilk olarak uygun şekilde kontrol edilmeyen duruma karşı koruma sağlamak için zincir boyunca koruyucu kod ekliyor. yerleştirmek; Daha sonra birisi sorun raporu alır ve belirli bir sorunun örneğine karşı daha fazla zırh ekler; başka bir kişi daha genel bir kontrol ekler ve daha önce belirli belirtilerle ilgilenen eski kodlardan bazılarını silmeyi unutur.

Öyleyse kod temizleme sorunu var: ölü kod gibi görünen şeyleri kaldırmak için özel bir teşvik yok ve yapmamaya yönelik büyük teşvik , çünkü kodu tamamen anlamıyorsanız, kodun "ölü" olduğuna dair değerlendirmeniz kusurlu olun, sistemi kırarak sarılırsınız.

• Hiçbir şey yapmayan yöntem veya işlev çağrıları.

Mutlaka kötü değil. Temel sınıftaki yöntemler genellikle alt sınıflar için geçersiz kılma noktaları olarak adlandırılan boş yöntemler olarak adlandırılır. Örnek: Cocoa Touch'ın UIView'ı, -didAddSubview:varsayılan sürümde hiçbir şey yapmadığı belgelenen bir yönteme sahiptir . UIView'un -addSubview:yöntemi -didAddSubview:hiçbir şey yapmamasına rağmen çağırmak zorundadır, çünkü alt sınıflar bir şeyi yapmak için uygulayabilir. Hiçbir şey yapmayan yöntemler ve bunların sebepleri elbette belgelenmelidir.

Boş ya da işe yaramaz bir işlev / yöntem, tarihsel nedenlerden dolayı açıkça varsa, eksize edilmelidir. Emin değilseniz, kaynak kod havuzunuzdaki kodun önceki sürümlerine bakın.

• Gereksiz kontroller ayrı bir sınıf dosyasında, nesne veya yöntemde yapılır.

Bazı bağlamlar olmadan tamam olup olmadığını söylemek zor. Kontroller aynı nedenden dolayı açıkça yapılırsa, sorumlulukların net bir şekilde ayrılmayacağı ve özellikle her iki kontrol de aynı önlemlerin alınmasına yol açtığında bazı yeniden düzenlemelerin yapılması gerektiği anlamına gelebilir. Her iki kontrolden kaynaklanan eylem aynı değilse, o zaman durum aynı olsa bile iki kontrole muhtemelen farklı sebepler yapılıyordur ve bu muhtemelen tamamdır.

• if deyimi her zaman doğru olarak değerlendirilir.

Şunlar arasında büyük bir fark var:

if (1) {
    // ...
}

ve:

if (foo() == true) {
    // ...
}

foo()her zaman geri dönmek için nerede olur true.

İlk vaka, insanlar hata ayıklarken çok olur. if (0) {...Bir hatayı izole etmeye çalışırken bir kod yığınını geçici olarak kaldırmak için bir kullanımı kolaydır ve daha sonra bu kodu geri yüklemek 0üzere değiştirilir 1. ifElbette, bitirdiğinizde kaldırılması gerektiğini, ancak bu adımı unutmak veya çeşitli yerlerde yaptık eğer bir ya da iki kaçırmak kolaydır. (Bu şartlamaları, daha sonra arayabileceğiniz bir yorumla tanımlamak iyi bir fikirdir.) Tek zararı, gelecekte neden olabileceği karışıklıktır; derleyici derleme zamanında koşulun değerini belirlerse, tamamen kaldırır.

İkinci durum kabul edilebilir olabilir. Temsil edilen koşulun foo()koddaki birkaç yerden test edilmesi gerekiyorsa, onu ayrı bir işleve veya yönteme dahil etmek, foo()her zaman şu anda doğru olsa bile, yapılacak en doğru şeydir . foo()Sonunda geri dönüşü düşünülebilecek olursa false, bu koşulu bir yöntem veya işlevde yalıtmak, kodun bu koşula dayandığı tüm yerleri tanımlamanın bir yoludur. Ancak , bunu yapmak, foo() == falsedurumun test edilmemesi ve daha sonra sorunlara yol açması riskini doğurur; Çözüm, falsevakayı açıkça sınayan birim testleri eklediğinizden emin olmaktır .

• Dönen ve hiçbir şey yapmayan konular.

Bu, tarihin bir eseri ve kod incelemesi sırasında veya yazılımın periyodik profili ile tanımlanabilecek bir şey gibi görünüyor. Ben varsayalım olabilir kasten yaratılabilir ama zor bir zaman aslında bilerek yapacağını kimse hayal var.

Olur. Aslında çok sık.

Bazen bu kodlama çıkmazları, etraflarına daha verimli / modern / hızlı bir otoyol kurulduğunda eski keçi izlerine benzemez.

Diğer durumlarda (ve bundan muhtemelen suçluyum), brifing verildiğinde yazılımın genişletilmesinin temelleridir, ancak onaylanmayan bir dizi özellik / işlev istendiğinde. (Bazen, ilk inşada "cıvata" yapmayı planladığınız daha sonraki işler için tutma kolları ve benzerlerini sağlayan bir parça iş koymak, daha fazla iş olmazsa, daha fazla veya daha zor / dağınık olması hayatı kolaylaştırabilir meydana gelmek.)

Ve bunun birçoğu doğrudan eski olan "Kırılmazsa sığmaz" dır. Bazen anlamadığınız veya kullanılmadığına inandığınız kodları ayırmak, "Kelebek Etkisi" nin programlama sürümüne neden olabilir. Bu da bir veya iki kere olmuş.

Bazen true değerine sahip global bir boolean'a sahip olurum ve daha sonra kodumda bir if (bool), sonra çalışma zamanı sırasında if ifadesinde bir kesme noktası ayarlayabilirim ve boolean'ı bir şey test etmek için değiştirebilirim.

if trueAyrı ayrı "anlamsız kod" olarak sınıflandırılması gereken ifadelere itiraz ediyorum .

if (1) { ... }Bir fonksiyonun başında değişken tanımları konusunda ısrar eden ya da sadece yerel değişkenlerin mümkün olduğunca yerel olarak tanımlanmasını isteyen C standardına uyumlu olmak isteyen C kodunda bir blok kullanmak için meşru bir durum var .

switch (i) {
    case 23:
        if (1) {
            /* I can declare a local var here! */
        }
        break;
}

Bir profesör, bir önceki işverenin, tamamladıkları sıra sayısına bağlı olarak ödeyeceği bir hikaye ile ilgili bize. Böylece, hiç çağrılmayan çok sayıda düzine çizgili fonksiyon yazdılar. Anlamsız kod yazmak için harika bir neden gibi görünüyor.

@Andy belirtildiği gibi, gördüğüm büyük bir bileşeni kırılıyor YAGNI .

Birisi , birçok öğenin ihtiyaç duyabileceği şey yerine tüm öğelerin ne olacağı üzerine bir varsayımla başlar; bu, "bir" ve " ilişki " ilişkilerinin bir karışıklığıdır .

Bu karışıklık, sağlam bir kalıtımsal yapıya yol açıyor ve daha sonra, aslında hiç çağrılmadıkları, bölümlerin ince ayarlanması gereken yerlerde tekrarlanan mantık ve iş modeline uymayan garip iş akışları nedeniyle uygulanmayan bırakılan yöntemlerdir.

Buradaki pek çok diğerleri gibi, bunun kötü niyetli bir şekilde yapıldığını görmedim, ancak iyi tasarım bilgisi ve başkalarına bu şekilde görünme girişimi eksikliği yüzünden. Komik, geliştiricilerin bu konuda daha az bilgili oldukları daha iyi görünüyor gibi görünüyor, çünkü en azından kodları aşırı tasarlanmış adaseumla bitmiyor. ( KISS prensibi )