Bir koşulun yan etkileri olması hiç bir zaman uygun mu? [kapalı]

Ara veri yapıları dersini Amerika'daki herkesin duyduğu bir üniversitede CS MS programına giriş için ön koşul olarak alıyorum. Sınıfta yazılan bir kod satırı gözüme çarptı:

if (a > 33 | b++ < 54) {...}

Bu benim işyerinde bir kod incelemesi geçmez. Bir röportajda böyle bir kod yazarsanız, bu size karşı önemli bir grev olacaktır. (Yan etkilerle şartlı olmanın yanı sıra, netlik pahasına zekidir.)

Aslında, yan etkileri olan bir koşul görmedim ve Googling de çok fazla ortaya çıkmadı. Başka bir öğrenci de bunu sormak için dersten sonra kaldı, bu yüzden bunun garip olduğunu düşünen tek kişi ben değilim. Ancak profesör bunun kabul edilebilir bir kod olduğu ve işte böyle bir şey yazacağı konusunda oldukça kararlıydı. (FT işi, hepinizin duyduğu bir şirkette Asıl SWE olarak çalışmaktadır.)

İstediğim gibi bu kod satırının kabul edilebilir olacağı bir dünya düşünemiyorum. Yanlış mıyım? Bu tamam mı? Daha genel durum ne olacak: yan etkileri olan şartlar? Bunlar iyi mi?

Orada bir ben sorun olur düşünebilirsiniz yarı koşullu yan etki:while(iter.MoveNext())

Bununla birlikte, bunun çoğunlukla " asla gerçekten büyük bir niteleyici" kategorisine girmediğini söyledi. Kabul edilebilir olduğunu gördüğüm birkaç nadir durum düşünebilirim , ancak genel olarak bu aşağılık ve kaçınılması gereken bir durumdur.

Ayrıca, belirli bir çizginin kabul edilebilir olacağı bir senaryo düşünemiyorum, ancak belirli bir çizginin yararlı olacağı bir senaryo da düşünemiyorum, bu yüzden içinde bulunduğu bağlamı hayal etmek zor.

Dünyamda, bellekten bir okuma bir yan etki olarak kabul edilebilir (örneğin, bellek eşlemeli G / Ç).

Şimdi aşağıdakileri göz önünde bulundurun:

    while( ( *memory_mapped_device_status_register & READY_FLAG) == 0) {
       // Wait
    }

Ve karşılaştırın:

    status = *memory_mapped_device_status_register;
    while( ( status & READY_FLAG) == 0) {
        // Wait
        status = *memory_mapped_device_status_register;
    }

Durumda yan etki (okuma) kaçınmak yardımcı okunabilirlik; ya da sadece kodu kopyalayıp dağınıklık mı ekledi?

Bir koşulun yan etkileri olması sorun yaratmaz (eğer kodu daha az okunabilir yaparsa) ve bir koşulun yan etkileri olması da sorun olmazsa (kod daha okunabilir hale gelirse). Anahtar faktör "okunabilirlik" tir. Diğer her şey, okunabilirliği iyileştirmek için yanlış yönlendirilmiş bir girişimde aptallar tarafından oluşturulan kurallardır (çoğu zaman tam tersi bir etki yaratırken).

Her zaman olduğu gibi bu tür sorularla, bu bir derece meselesidir. Bir ifadedeki herhangi bir yan etkinin her zaman daha kötü bir koda yol açtığına dair kesin bir kanıt olsaydı, bu ifadeleri oluşturmak yasal olmazdı. Dil tasarımcıları ideosenkrat, yanıltıcı insanlar olabilir, ama o kadar aptal değiller .if

Bununla birlikte, bir içindeki haklı yan etkilere örnekler ifnelerdir? Örneğin, denetim amacıyla Pbir işletmenin mülküne tüm erişimi ve erişimi kaydetmeniz gerektiğini yasal olarak varsayalım E. (Bir uranyum zenginleştirme tesisinde çalıştığınızı ve kodunuzun ne yapmasına izin verildiğine ve bunu nasıl yapması gerektiğine dair çok sıkı yasal kontroller olduğunu hayal edin.) Sonra ifbu özelliği kontrol eden her şey, denetim günlüğü genişletiliyor.

Bu oldukça net bir kesişen endişe, program durumu hakkındaki düşüncelerinizi etkilemez (çok) ve uygulayabilirsiniz, böylece satırı if(gizli) ile gözden geçirdiğinizde tamamen görünmez ve dikkat dağıtıcı değildir. uzakta, hatta daha iyi AOP aracılığıyla). Endişe etmeyen bir yan etkinin oldukça açık bir örneği olduğunu söyleyebilirim. Profil oluşturma amacıyla şube işlemlerini saymak istediğinizde benzer durumlar düşünülebilir.

Bu hafifletici koşullar ne kadar ortadan kaybolursa, yapı ne kadar yabancı olur. Belirli bir döngü türü (örneğin if((c = getc()) == 'x') { quit(); }, dil topluluğu tarafından iyi bilinir ve kabul edilirse, kendiliğinden icat ettiğiniz zamandan çok daha az problemdir, vb. Örnek hattınız bu standardın altında kalıyor, ancak çok, çok hayal edebiliyorum daha korkunç olanları bile yazamayacağım, çok korkunçlar.

Gerçekten kötü kokulu kod olmasına rağmen, eşdeğerden daha basit (ve belki de iyi bir optimize edici derleyiciniz yoksa belki daha hızlı) olma avantajına sahiptir. if (a > 33 | b < 54) {b++; ...} else b++;

ancak elbette bunu aşağıdakilere göre optimize etmek mümkündür (ancak dikkat edin! taşma durumunda bunun farklı bir davranışı vardır!): b++; if (a > 33 | b < 53) {...}