Yuvalamayı azaltmak için “if” ifadesini ters çevirin

Kodumda ReSharper'ı çalıştırdığımda , örneğin:

    if (some condition)
    {
        Some code...            
    }

ReSharper bana yukarıdaki uyarıyı verdi (yuvalamayı azaltmak için "if" ifadesini ters çevir) ve aşağıdaki düzeltmeyi önerdi:

   if (!some condition) return;
   Some code...

Bunun neden daha iyi olduğunu anlamak istiyorum. Her zaman bir yöntemin ortasında "dönüş" kullanmanın biraz "goto" gibi sorunlu olduğunu düşündüm.

Yöntemin ortasındaki bir dönüş mutlaka kötü değildir. Kodun amacını daha net hale getirirse, hemen geri dönmek daha iyi olabilir. Örneğin:

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
     return result;
};

Bu durumda, _isDeaddoğruysa, hemen yöntemden çıkabiliriz. Bunun yerine bu şekilde yapılandırmak daha iyi olabilir:

double getPayAmount() {
    if (_isDead)      return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired)   return retiredAmount();

    return normalPayAmount();
};   

Bu kodu yeniden düzenleme kataloğundan aldım . Bu özel yeniden düzenleme denir: İç İçe Koşullu Muhafız Cümleleriyle Değiştir.

Sadece estetik değil , aynı zamanda yöntemin içindeki maksimum yuvalama seviyesini de azaltır . Bu genellikle bir artı olarak kabul edilir, çünkü yöntemleri daha kolay anlaşılır hale getirir (ve aslında birçok statik analiz aracı , bunun kod kalitesinin göstergelerinden biri olarak bir ölçü sağlar).

Öte yandan, yönteminizin birden fazla çıkış noktasına sahip olmasını sağlar, başka bir grup insanın hayır olduğuna inandığı bir şey.

Şahsen, ReSharper ve ilk gruba katılıyorum (istisnaları olan bir dilde "çoklu çıkış noktaları" nı tartışmayı aptalca buluyorum; neredeyse her şey fırlatabilir, bu yüzden tüm yöntemlerde çok sayıda potansiyel çıkış noktası vardır).

Performansla ilgili olarak : her iki sürüm de her dilde eşdeğer olmalıdır (IL düzeyinde değilse, o zaman kesinlikle jitter koddan geçtikten sonra). Teorik olarak bu derleyiciye bağlıdır, ancak pratikte günümüzde yaygın olarak kullanılan herhangi bir derleyici, bundan daha gelişmiş kod optimizasyonu durumlarını işleyebilir.

Bu biraz dini bir argüman, ama ReSharper ile daha az yuva yapmayı tercih etmene katılıyorum. Bunun bir fonksiyondan çoklu dönüş yollarına sahip olmanın olumsuzluklarından daha ağır bastığına inanıyorum.

Daha az yuvaya sahip olmanın temel nedeni, kod okunabilirliğini ve sürdürülebilirliğini artırmaktır . Diğer birçok geliştiricinin gelecekte kodunuzu okuması gerektiğini ve daha az girintili kodun okunması genellikle daha kolay olduğunu unutmayın.

Önkoşullar , işlevin başlangıcında erken dönmenin uygun olduğu durumlara harika bir örnektir. Fonksiyonun geri kalanının okunabilirliği neden bir önkoşul kontrolünün varlığından etkilenmelidir?

Bir yöntemden birden çok kez geri dönmeyle ilgili olumsuzluklara gelince - hata ayıklayıcılar şimdi oldukça güçlüdür ve belirli bir işlevin tam olarak nerede ve ne zaman döndüğünü bulmak çok kolaydır.

Bir işlevde birden fazla geri dönüş olması bakım programcısının işini etkilemez.

Kötü kod okunabilirliği olacaktır.

Diğerlerinin de belirttiği gibi, bir performans isabeti olmamalı, ancak başka hususlar da var. Bu geçerli endişelerin yanı sıra, bu sizi bazı durumlarda gotcha'lara da açabilir. Bir bununla uğraştığınızı varsayalım double:

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

Görünüşte eşdeğer ters çevirme ile kontrast :

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

Bu nedenle, bazı durumlarda doğru bir şekilde ters çevrilmiş gibi görünen ifşey olmayabilir.

Sadece bir fonksiyonun sonunda geri dönme fikri, dillerin istisnaları desteklemesinden önceki günlerden döndü. Programların, bir yöntemin sonuna temizleme kodu koyabileceğine ve ardından çağrıldığından ve diğer bazı programcıların, temizleme kodunun atlanmasına neden olan yöntemde bir dönüşü gizlemeyeceğinden emin olmasını sağladı. . Atlanan temizleme kodu bellek veya kaynak sızıntısına neden olabilir.

Ancak, istisnaları destekleyen bir dilde, böyle bir garanti vermez. İstisnaları destekleyen bir dilde, herhangi bir ifadenin veya ifadenin yürütülmesi, yöntemin sona ermesine neden olan bir kontrol akışına neden olabilir. Bu, temizleme işleminin nihayet veya anahtar kelimeler kullanılarak yapılması gerektiği anlamına gelir.

Her neyse, birçok insanın neden iyi bir şey olduğunu anlamadan 'bir yöntemin sonunda geri dönüş' kılavuzundan alıntı yaptığını ve okunabilirliği artırmak için yuvalamanın azaltılmasının muhtemelen daha iyi bir amaç olduğunu düşünüyorum.

Ben ters çevrilmiş olanlar için bir isim olduğunu eklemek istiyorum - Guard Clause. Mümkün olduğunca kullanıyorum.

Başlangıçta, iki kod ekranı ve başka hiçbir yerde kod okuma nefret ediyorum. Sadece ters çevir ve geri dön. Bu şekilde kimse kaydırma zamanını boşa harcamaz.

http://c2.com/cgi/wiki?GuardClause

Sadece estetiği etkilemekle kalmaz, aynı zamanda kod yerleştirmeyi de önler.

Verilerinizin de geçerli olduğundan emin olmak için bir ön koşul olarak işlev görebilir.

Bu elbette özneldir, ancak bence iki noktada güçlü bir şekilde gelişir:

• Artık işlevinizin conditionbekletilirse yapacak hiçbir şeyi kalmayacağı hemen ortadadır .
• Yuvalama seviyesini düşük tutar. Yuvalamak, okunabilirliği düşündüğünüzden daha fazla incitir.

Birden çok dönüş noktası C'de (ve daha az ölçüde C ++) bir problemdi, çünkü sizi her dönüş noktasından önce temizleme kodunu kopyalamaya zorladılar. Çöp toplama ile try| finallyyapı ve usingbloklar, onlardan korkmanız için hiçbir neden yok.

Nihayetinde, sizin ve iş arkadaşlarınızın okumayı daha kolay buldukları şey gelir.

Performans açısından, iki yaklaşım arasında gözle görülür bir fark olmayacaktır.

Ancak kodlama performanstan daha fazlasıdır. Netlik ve sürdürülebilirlik de çok önemlidir. Ve performansı etkilemediği gibi durumlarda önemli olan tek şey budur.

Hangi yaklaşımın tercih edileceğine dair rakip düşünce okulları vardır.

Bir görüş, diğerlerinin bahsettiği görüştür: ikinci yaklaşım, kodlama netliğini artıran yuvalama seviyesini azaltır. Bu zorunlu bir tarzda doğaldır: yapacak bir şeyin kalmadıysa, erken dönebilirsin.

Daha işlevsel bir stil açısından başka bir görüş, bir yöntemin sadece bir çıkış noktasına sahip olmasıdır. İşlevsel bir dilde her şey bir ifadedir. Yani eğer ifadelerin her zaman başka bir cümlesi olmalıdır. Aksi takdirde, if ifadesinin her zaman bir değeri olmaz. Yani fonksiyonel tarzda, ilk yaklaşım daha doğal.

Koruma hükümleri veya ön koşullar (muhtemelen görebileceğiniz gibi) belirli bir koşulun karşılanıp karşılanmadığını kontrol edin ve ardından programın akışını kırar. Gerçekten sadece bir ififadenin tek bir sonucuyla ilgilendiğiniz yerler için harikadır . Söylemek yerine:

if (something) {
    // a lot of indented code
}

Koşulu tersine çevirirsiniz ve bu ters koşul yerine getirilirse kırılırsınız

if (!something) return false; // or another value to show your other code the function did not execute

// all the code from before, save a lot of tabs

returnkadar kirli değil goto. Kodunuzun geri kalanını işlevin çalışamayacağını göstermek için bir değer iletmenizi sağlar.

Bunun iç içe koşullarda nereye uygulanabileceğine ilişkin en iyi örnekleri göreceksiniz:

if (something) {
    do-something();
    if (something-else) {
        do-another-thing();
    } else {
        do-something-else();
    }
}

vs:

if (!something) return;
do-something();

if (!something-else) return do-something-else();
do-another-thing();

İlkinin daha temiz olduğunu iddia eden birkaç kişi bulacaksınız, ancak elbette tamamen öznel. Bazı programcılar, bir şeyin girintiyle hangi koşulların altında çalıştığını bilmek isterken, yöntem akışını doğrusal tutmayı tercih ederim.

Bir an için precons'un hayatınızı değiştireceğini veya sizi koyacağını önermeyeceğim, ancak kodunuzu okumak biraz daha kolay olabilir.

Burada birkaç iyi nokta vardır, ancak yöntem çok uzunsa, birden fazla dönüş noktası da okunamaz olabilir . Bununla birlikte, birden fazla dönüş noktası kullanacaksanız, yönteminizin kısa olduğundan emin olun, aksi takdirde birden fazla dönüş noktasının okunabilirlik bonusu kaybedilebilir.

Performans iki bölümden oluşmaktadır. Yazılım üretilirken performansınız var, ancak geliştirme ve hata ayıklama sırasında da performans elde etmek istiyorsunuz. Bir geliştiricinin istediği son şey önemsiz bir şey için "beklemektir". Sonunda, bunu optimizasyon etkinken derlemek benzer bir kodla sonuçlanacaktır. Bu yüzden her iki senaryoda da işe yarayan bu küçük hileleri bilmek güzel.

Söz konusu dava açık, ReSharper doğru. ifİfadeleri yerleştirmek ve kodda yeni bir kapsam oluşturmak yerine , yönteminizin başlangıcında açık bir kural belirlersiniz. Okunabilirliği artırır, bakımı daha kolay olur ve nereye gitmek isterse bulmak için elemek zorunda olduğu kuralların miktarını azaltır.

Şahsen ben sadece 1 çıkış noktasını tercih ediyorum. Metodlarınızı kısa ve dikkat çekici bir şekilde tutarsanız başarmak kolaydır ve kodunuz üzerinde çalışan bir sonraki kişi için öngörülebilir bir desen sağlar.

Örneğin.

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

      DataStructure defaultParameters;
      if ((defaultParameters = this.GetApplicationDefaults()) != null)
      {
           succeeded = this.DoSomething(defaultParameters);
      }

      return succeeded;
 }

Bu, bir işlevden çıkmadan önce belirli yerel değişkenlerin değerlerini kontrol etmek istiyorsanız da çok kullanışlıdır. Yapmanız gereken tek şey son dönüşe bir kırılma noktası yerleştirmek ve (bir istisna atılmadıkça) vurmanız garanti edilir.

Kodun nasıl göründüğüne dair birçok iyi neden . Peki ya sonuçlar ?

Bazı C # koduna ve IL derlenmiş formuna bir göz atalım:

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length == 0) return;
        if ((args.Length+2)/3 == 5) return;
        Console.WriteLine("hey!!!");
    }
}

Bu basit snippet derlenebilir. Oluşturulan .exe dosyasını ildasm ile açabilir ve sonucun ne olduğunu kontrol edebilirsiniz. Tüm birleştirici şeyi göndermeyeceğim ama sonuçları açıklayacağım.

Oluşturulan IL kodu aşağıdakileri yapar:

1. İlk koşul yanlışsa, ikincisinin bulunduğu koda atlar.
2. Eğer bu doğruysa son talimata atlar. (Not: son talimat bir dönüştür).
3. İkinci durumda, sonuç hesaplandıktan sonra aynı şey olur. Karşılaştır ve: yanlışsa Console.WriteLine'a veya bu doğruysa sonuna kadar var.
4. Mesajı yazdırın ve geri dönün.

Yani kod sonuna kadar atlayacak gibi görünüyor. Yuvalanmış kodla normal yaparsak ne olur?

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length != 0 && (args.Length+2)/3 != 5) 
        {
            Console.WriteLine("hey!!!");
        }
    }
}

Sonuçlar IL talimatlarında oldukça benzerdir. Fark şudur ki, koşul başına atlamalar yapılmadan önce: false ise sonraki kod parçasına gider, true ise biter. Ve şimdi IL kodu daha iyi akıyor ve 3 atlama var (derleyici bunu biraz optimize etti): 1. İlk atlama: Uzunluk 0 olduğunda kodun tekrar atladığı (Üçüncü atlama) bir parçaya. 2. İkinci: bir talimattan kaçınmak için ikinci koşulun ortasında. 3. Üçüncüsü: ikinci koşul yanlışsa sonuna kadar atlayın.

Her neyse, program sayacı her zaman atlayacaktır.

Teoride, ifdal tahmini isabet oranını arttırırsa ters çevirme daha iyi performans sağlayabilir. Uygulamada, özellikle de derlemeden sonra, şube tahmininin nasıl davranacağını bilmek çok zor olduğunu düşünüyorum, bu yüzden derleme kodunu yazmam dışında günlük gelişimimde bunu yapmayacağım.

Burada şube tahmini hakkında daha fazla bilgi .

Bu sadece tartışmalıdır. Erken dönüş konusunda “programcılar arasında bir anlaşma” yoktur. Bildiğim kadarıyla her zaman özneldir.

Bir performans argümanı yapmak mümkündür, çünkü çoğu zaman doğru olmak için yazılı koşullara sahip olmak daha iyidir; bunun daha net olduğu da iddia edilebilir. Öte yandan, iç içe geçmiş testler oluşturur.

Bu soruya kesin bir cevap alacağınızı sanmıyorum.

Zaten orada çok fazla anlayışlı cevap var, ama yine de, biraz farklı bir duruma yönelirdim: Önkoşul yerine, bu gerçekten bir fonksiyonun üzerine konulmalı, adım adım başlatmayı düşünün, burada başarılı olmak için her adımı kontrol etmeniz ve ardından bir sonraki adımla devam etmeniz gerekir. Bu durumda, üstteki her şeyi kontrol edemezsiniz.

Yuvalama paradigmasını izlediğim için Steinberg ASIOSDK ile bir ASIO ana bilgisayar uygulaması yazarken kodumu gerçekten okunamaz buldum. Sekiz kat derinliğe inmişti ve yukarıda Andrew Bullock'un belirttiği gibi bir tasarım kusuru göremiyorum. Tabii ki, başka bir işleve bazı iç kodları paketleyebilir ve daha sonra okunabilir hale getirmek için orada kalan seviyeleri iç içe olabilirdi, ama bu benim için oldukça rastgele görünüyor.

Yuvaları nöbet cümleleriyle değiştirerek, temizleme kodunun, işlev yerine daha önce yerine çok daha önce ortaya çıkması gereken bir kısmı ile ilgili bir yanlış anlama bile keşfettim. İç içe geçmiş dallarda, bunu asla göremezdim, yanlış anlamama yol açtıklarını bile söyleyebilirdiniz.

Bu nedenle, ters çevrilmiş kodların daha açık bir koda katkıda bulunabileceği başka bir durum olabilir.

Birden çok çıkış noktaları kaçınmak olabilir performans kazançları yol açar. C # hakkında emin değilim ama C ++ 'da Adlandırılmış Dönüş Değeri Optimizasyonu (Kopya Elision, ISO C ++ '03 12.8 / 15) tek bir çıkış noktasına sahip olmasına bağlıdır. Bu optimizasyon, dönüş değerinizi oluşturan kopyayı önler (özel örneğinizde önemli değildir). Bu, her işlev çağrıldığında bir yapıcı ve bir yıkıcı kaydettiğiniz için sıkı döngülerde önemli ölçüde performans kazanımlarına yol açabilir.

Ancak, ek kurucu ve yıkıcı çağrılarını saklayan vakaların% 99'u için, iç içe ifblokların getirdiği okunabilirlik kaybına değmez (diğerleri işaret ettiği gibi).

Bu bir görüş meselesi.

Benim normal yaklaşım tek satır ifs önlemek ve bir yöntemin ortasında döndürmek olacaktır.

Yönteminizin her yerinde önerdiği gibi satırlar istemezsiniz, ancak yönteminizin üst kısmında bir grup varsayımı kontrol etmek ve yalnızca hepsi geçerse gerçek işinizi yapmak için söylenecek bir şey vardır.

Bence sadece geri dönüşü (ya da hiç kontrol etmeyeceğiniz işe yaramaz bir dönüş kodunu) iade ediyorsanız erken dönüş iyidir ve iç içe geçmekten kaçındığınız ve aynı zamanda işlevinizin açık olduğunu belirlediğiniz için okunabilirliği artırabilir.

Aslında bir returnValue döndürüyorsanız - yuvalama genellikle gitmenin daha iyi bir yoludur, returnValue'unuzu yalnızca bir yerde (sonunda - duh) döndürmenize neden olur ve kodunuzu birçok durumda daha sürdürülebilir hale getirebilir.

Emin değilim, ama bence, R # uzak atlamalar kaçınmaya çalışır. IF-ELSE varsa, derleyici böyle bir şey yapar:

Koşul false -> false_condition_label öğesine çok atlama

true_condition_label: yönerge1 ... yönerge_n

false_condition_label: yönerge1 ... yönerge_n

son blok

Koşul doğruysa atlama ve L1 önbellek yok, ancak false_condition_label'e atlamak çok uzak olabilir ve işlemci kendi önbelleğini sunmalıdır. Önbelleği senkronize etmek pahalıdır. R #, kısa atlamaların yerine uzun atlamaları değiştirmeye çalışır ve bu durumda, tüm talimatların zaten önbellekte olması olasılığı daha yüksektir.

Bence bu sizin tercih ettiğiniz şeye bağlı, belirtildiği gibi, genel bir anlaşma yok. Rahatsızlığı azaltmak için bu tür bir uyarıyı "İpucu" olarak azaltabilirsiniz.

Benim fikrim, "bir fonksiyonun ortasında" geri dönüşünün "öznel" olmaması gerektiğidir. Nedeni oldukça basit, bu kodu alın:

    işlev do_something (data) {

      if (! is_valid_data (veri)) 
            yanlış döndür;


       do_something_that_take_an_hour (veri);

       istance = yeni object_with_very_painful_constructor (veri);

          if (istance geçersiz) {
               hata mesajı( );
                dönüş ;

          }
       connect_to_database ();
       get_some_other_data ();
       dönüş;
    }

Belki ilk "dönüş" çok sezgisel değil, ama bu gerçekten tasarruf. Temiz kodlar hakkında "öznel" kötü fikirlerini kaybetmek için daha fazla uygulamaya ihtiyaç duyan çok fazla "fikir" vardır.

Bu tür kodlamanın birkaç avantajı vardır, ancak benim için büyük kazanç, hızlı dönebilirseniz, uygulamanızın hızını artırabilirsiniz. IE Önkoşul X nedeniyle bir hata ile hızlı bir şekilde geri dönebileceğini biliyorum. Bu, önce hata durumlarından kurtulur ve kodunuzun karmaşıklığını azaltır. Birçok durumda cpu boru hattı daha temiz olabileceğinden, boru hattı çökmelerini veya anahtarlarını durdurabilir. İkincisi, bir döngüde iseniz, hızlı bir şekilde kırılma veya geri dönme size çok fazla işlemci kazandırabilir. Bazı programcılar bu tür hızlı çıkış yapmak için döngü değişmezlerini kullanırlar, ancak bu işlemde cpu boru hattınızı bozabilir ve hatta bellek arama sorunu yaratabilir ve cpu'nun dış önbellekten yüklenmesi gerekir. Ama temelde istediğini yapmalısın, döngü veya işlev sonlandırılması, sadece doğru kodun bazı soyut kavramını uygulamak için karmaşık bir kod yolu oluşturmaz. Sahip olduğunuz tek alet bir çekiçse, her şey bir çivi gibi görünür.