Bloktaki ek satır - Temiz Koddaki ek parametre

bağlam

In Temiz Kod , sayfa 35, diyor

Bu, if ifadelerindeki blokların, başka ifadelerin, while ifadelerinin vb. Bir satır uzunluğunda olması gerektiği anlamına gelir. Muhtemelen bu hat bir işlev çağrısı olmalıdır. Bu sadece çevreleyen işlevi küçük tutmakla kalmaz, aynı zamanda belgesel değeri de ekler çünkü blok içinde çağırılan işlev güzel bir tanımlayıcı ada sahip olabilir.

Tamamen hemfikir, bu çok mantıklı.

Daha sonra, sayfa 40'ta fonksiyon argümanları hakkında yazıyor

Bir fonksiyon için ideal argüman sayısı sıfırdır (niladik). Daha sonra bir (monadik) geliyor, ardından iki (dyadic) yakından takip ediyor. Mümkünse üç argümandan (üçlü) kaçınılmalıdır. Üçten fazla (polyadik) çok özel bir gerekçe gerektirir - ve daha sonra kullanılmamalıdır. Argümanlar zor. Çok fazla kavramsal güç alıyorlar.

Tamamen hemfikir, bu çok mantıklı.

Konu

Ancak, sık sık kendimi başka bir listeden bir liste oluştururken buluyorum ve iki kötülükten biriyle yaşamak zorunda kalacağım.

Ya blokta iki satır kullandım , biri şeyi yaratmak için, biri sonucu eklemek için:

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            Flurp flurp = CreateFlurp(badaBoom);
            flurps.Add(flurp);
        }
        return flurps;
    }

Veya listenin fonksiyonuna bir şeyin argümanını ekleyerek, "bir argümanı daha kötü" yapar.

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            CreateFlurpInList(badaBoom, flurps);
        }
        return flurps;
    }

Soru

Bunlardan birini genel olarak tercih eden, göremediğim (dis-) avantajlar var mı? Veya bazı durumlarda böyle avantajlar var mı; Bu durumda karar verirken nelere dikkat etmeliyim?

Bu kurallar bir pusuladır, harita değildir. Seni mantıklı bir yöne işaret ediyorlar . Ancak, size hangi çözümün “en iyi” olduğunu kesin olarak söyleyemezler. Bir noktada pusulanızın gösterdiği yöne doğru yürümeyi bırakmanız gerekir, çünkü varış noktanıza geldiniz.

Temiz Kod, kodunuzu çok küçük ve belirgin bloklara bölmenizi önerir. Bu genel olarak iyi bir yöndür. Ancak en uç noktaya alındığında (alıntı yapılan tavsiyelerin tam anlamıyla yorumlanmasının önerdiği gibi), o zaman kodunuzu gereksiz yere küçük parçalara böldünüz. Hiçbir şey gerçekten bir şey yapmaz, her şey delege eder. Bu aslında başka bir tür kod gizliliğidir.

“Daha küçük daha iyidir” ile “çok küçük işe yaramaz” a dengelemek sizin işinizdir. Hangi çözümün daha basit olduğunu kendinize sorun. Benim için açıkça belli olan bir liste oluşturduğu için ilk çözüm budur . Bu iyi anlaşılmış bir deyimdir. Başka bir işleve bakmak zorunda kalmadan bu kodu anlamak mümkündür.

Daha iyisini yapmak mümkün ise, “tüm elemanları bir listeden başka bir listeye dönüştür” ün, işlevsel bir map()işlem kullanarak soyutlanabilen genel bir kalıp olduğunu belirtmek gerekir . C #, bence denir Select. Bunun gibi bir şey:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(BadaBoom => CreateFlurp(badaBoom)).ToList();
}

Bir işlev için ideal argüman sayısı sıfırdır (niladik)

Yok hayır! Bir işlev için ideal argüman sayısı birdir. Sıfır ise, bir eylem gerçekleştirebilmek için işlevin dış bilgilere erişmesi gerektiğini garanti edersiniz. "Amca" Bob bunu çok yanlış anladı.

Kodunuzla ilgili olarak, ilk örneğiniz blokta yalnızca iki satır içeriyor, çünkü ilk satırda yerel bir değişken oluşturuyorsunuz. Bu ödevi kaldırın, bu temiz kod yönergelerine uyuyorsunuz:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    List<Flurp> flurps = new List<Flurp>();
    foreach (BadaBoom badaBoom in badaBooms)
    {
        flurps.Add(CreateFlurp(badaBoom));
    }
    return flurps;
}

Ama bu çok uzun zamandır solmuş (C #) kod. Sadece şu şekilde yapın:

IEnumerable<Flurp> CreateFlurps(IEnumerable<BadaBoom> badaBooms) =>
    from badaBoom in babaBooms select CreateFlurp(badaBoom);

'Temiz Kod' Tavsiyesi tamamen yanlıştır.

Döngünüzde iki veya daha fazla satır kullanın. Bir fonksiyonda aynı iki çizgiyi saklamak, bir açıklama gerektiren rasgele bir matematik olduklarında anlamlıdır, ancak çizgiler zaten açıklayıcı olduğunda hiçbir şey yapmaz. 'Oluştur' ve 'Ekle'

Bahsettiğiniz ikinci yöntem hiçbir anlam ifade etmiyor, çünkü iki satırı önlemek için ikinci bir argüman eklemek zorunda değilsiniz.

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            flurps.Add(badaBoom .CreateFlurp());
            //or
            badaBoom.AddToListAsFlurp(flurps);
            //or
            flurps.Add(new Flurp(badaBoom));
            //or
            //make flurps a member of the class
            //use linq.Select()
            //etc
        }
        return flurps;
    }

veya

foreach(var flurp in ConvertToFlurps(badaBooms))...

Diğerleri tarafından belirtildiği gibi, en iyi işlevin tartışmasız olduğu yönündeki tavsiye, en iyi ihtimalle OOP'a ve en kötüsü de kötü öneriye çarpıktır.

İkincisi, CreateFlurpInListlisteyi kabul ettiği ve değiştirdiği için işlevi daha da saflaştırır, çünkü işlevi saf değil ve nedenini zorlaştırır. Yöntem adındaki hiçbir şey, yöntemin yalnızca listeye eklendiğini göstermez.

Ve üçüncü, en iyi seçeneği sunuyoruz:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(CreateFlurp).ToList();
}

Ve cehennem, tek bir astar kendiliğinden açık olduğu için, kullanıldığı yerde yalnızca bir yer varsa, bu yöntemi hemen kullanabilirsiniz, bu yüzden anlam vermek için yöntemle kapsüllenmesi gerekmez.

Bir argüman sürümü daha iyi, ancak öncelikle argüman sayısı nedeniyle değil.

Daha iyi olmasının en önemli nedeni, daha az kapline sahip olmasıdır , bu da daha kullanışlı, nedene göre daha kolay, test edilmesi daha kolay ve kopyalanan + kopyalanan klonlara dönüşme olasılığı daha düşüktür.

Eğer bir bana sağlarsanız CreateFlurp(BadaBoom)Basit: Ben toplama kabının herhangi bir tür onu kullanabilirsiniz Flurp[], List<Flurp>, LinkedList<Flurp>, Dictionary<Key, Flurp>, vb. Ancak, bir ile CreateFlurpInList(BadaBoom, List<Flurp>), CreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)görüş modelimin listenin değiştiği bildirimini alabilmesi için yarın rica ediyorum. Yuck!

Ek bir avantaj olarak, basit imzanın mevcut API'lara uyması daha olasıdır. Sürekli bir problemin olduğunu söylüyorsun

oldukça sık kendimi başka bir listeden bir liste oluştururken buluyorum

Sadece mevcut araçları kullanma meselesi. En kısa, en verimli ve en iyi sürüm:

var Flurps = badaBooms.ConvertAll(CreateFlurp);

Yazmanız ve test etmeniz için sadece bu daha az kod değil, aynı zamanda daha hızlıdır, çünkü List<T>.ConvertAll()sonucun girdiyle aynı sayıda öğeye sahip olacağını bilecek kadar akıllıdır ve sonuç listesini doğru boyuta önceden dağıtırsınız. Kodunuz (her iki versiyonda da) listeyi büyütmek için gerekliydi.

Genel amacı göz önünde bulundurun: kodu okumasını ve sürdürmesini kolaylaştırmak.

Genellikle, birden çok satırı tek ve anlamlı bir işlevde gruplamak mümkün olacaktır. Bu gibi durumlarda yapın. Bazen, genel yaklaşımınızı yeniden gözden geçirmeniz gerekir.

Örneğin, sizin durumunuzda tüm uygulamanın var ile değiştirilmesi

flups = badaBooms.Select(bb => new Flurp(bb));

bir olasılık olabilir. Veya böyle bir şey yapabilirsin

flups.Add(new Flurp(badaBoom))

Bazen, en temiz ve en okunabilir çözüm basitçe bir satıra sığmayabilir. Yani iki satırın olacak. Kodun anlaşılmasını zorlaştırmayın, sadece bazı keyfi kuralları yerine getirmek için.

İkinci örneğiniz (bence) ilkinden daha anlaşılması zor. Sadece ikinci bir parametrenizin değil, parametrenin fonksiyon tarafından değiştirilmesidir. Bu konuda Temiz Kod'un söylediklerine bakın. (Kitabı şu anda elinizde bulundurmayın, ancak temelde "bunu önleyebiliyorsanız yapmayın" yazdığından eminim).