Yorum değiştirme olarak ek yerel değişkenlerin tanıtılması

Olanları tanımlamak için ek, teknik olarak gereksiz yerel değişkenler kullanmak iyi bir stil midir?

Örneğin:

bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);

if(easyUnderstandableIsTrue)
{
    // ...
}

Teknik yük söz konusu olduğunda, derleyicinin bu ek hattı optimize etmesini bekliyorum. Ancak gereksiz bir kod şişmesi olarak mı kabul edilir? Gözlerimde eski yorum riskini azaltır.

Ek bir değişkene sahip olmanın maliyeti nedir? Çoğu dilde, hiçbiri, hem derlenmiş hem de yorumlanmış dillerde.

Bunun yararı ne?

• Şifreli boole ifadesini ayrı bir yönteme çıkarmak gibi , çoğaltılmış kod riskini de azaltırsınız , ancak ayrı bir yöntemden biraz daha azdır. Koşullu ifade yöntemin içinde yeniden kullanılırsa, değişkeni yeniden kullanabilirsiniz; ifade farklı bir yöntemde görünürse, olmaz.

  Programlama diliniz değişmez yerel değişkenlere sahip olmanıza izin vermedikçe veya stil açısından zorlama yolunuz yoksa, değişkenlerin hiçbirinin yeniden atanmadığını, bu yeniden düzenleme uzun vadede riskli olabileceğini unutmayın. Değişkenin değeri değiştirilirse, kod hakkında muhakeme yapmak çok zor olabilir.

• Sen edilmektedir dokümantasyon koduyla senkronizasyon dışı yakalanma riskini azaltarak . Geliştiriciler, değişkenlerin ve yöntemlerin adlarını yorumlardan daha kolay güncelleme eğilimindedir.¹ Bu nedenle, aşağıdaki gibi kodları görmek alışılmadık bir durum değildir:

    // Find if the user is an actual author in order to allow her to edit the message.
    if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))

İfade muhtemelen başlamış if (message.author == currentUser)ve daha sonra yazar olması gerekmeyen ve kilitli şeyleri umursamayan kilitli mesajların ve yöneticilerin durumunu ele alacak şekilde gelişmiştir; ancak yorum bu değişikliklerin hiçbirini yansıtmamıştır.

Her iki fayda da özellikle önemli değildir, ancak ek değişkenlerin düşük maliyeti göz önüne alındığında, gerçekten bunları kullanmayı düşünebilirsiniz.

Boole ifadeniz aşırı karmaşık hale gelirse: ²

• Ayrı bir yönteme çıkarın ve:
• Birden çok basit boole ifadesine yeniden bakın.

Yukarıdaki örnek:

class Message
{
    ...
    public boolean canBeEditedBy(User user)
    {
        ...
        if (user.isAdministrator) {
            return true;
        }

        return this.author == user && !this.locked;
    }
}

...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
    ...
}

^{¹ Kaynak: çoğunlukla iş yazılımları geliştiren yaşıtlarımın kendi gözlemim; YMMV. Gerçek bir araştırma farklı sonuçlar verebilir. Şahsen, geliştiricilerin kod okurken, bunlar durduğunu varsayalım kodu ve yorumlar belgeler, değil kodudur; bu nedenle, genellikle yorumları okumazlar, bu yüzden onları güncellemelerini beklemek zor olacaktır.}

^{² Aşırı karmaşık eşik basit bir formülle tanımlanır: kodunuzu inceleyen geliştiricilerin yarısı sizi öldürme niyetini ifade ederse, eşiğe ulaşılır. Yukarıdaki boole ifadesi yeniden düzenleme gerektirecek kadar basittir; ancak, arka arkaya dört bölüm if ((a && b) || (c && d))potansiyel olarak yeniden düzenlenebilir olmasını sağlayacaktır. İfade düz ise, parça sayısının çoğunlukla alakasız olduğunu unutmayın: if (a || b || c || d || ... || z)yeterince okunabilir.}