Bir void yöntemi içinde return kullanmak kötü bir uygulama mıdır?

Aşağıdaki kodu hayal edin:

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

Bir void yöntemi içinde dönüş kullanmak uygun mudur? Performans cezası var mı? Veya şöyle bir kod yazmak daha iyi olur:

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

Boşluk yönteminde geri dönüş kötü değildir, iç içe geçmeyi azaltmak için ifadeleri ters çevirmekif yaygın bir uygulamadır .

Yöntemlerinize daha az yerleştirme yapmak, kod okunabilirliğini ve sürdürülebilirliğini artırır.

Aslında, herhangi bir return ifadesi olmayan bir void yönteminiz varsa, derleyici her zaman sonunda bir ret talimatı oluşturacaktır .

Korumaları kullanmanın başka bir harika nedeni daha vardır (iç içe geçmiş kodun aksine): Başka bir programcı işlevinize kod eklerse, daha güvenli bir ortamda çalışırlar.

Düşünmek:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

karşı:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

Şimdi, başka bir programcının şu satırı eklediğini hayal edin: obj.DoSomethingElse ();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

Açıkçası bu basit bir durumdur, ancak programcı ilk (iç içe kod) durumda programa bir çökme eklemiştir. İkinci örnekte (korumalarla erken çıkış), korumayı geçtiğinizde, kodunuz bir boş referansın kasıtsız kullanımından korunur.

Elbette, harika bir programcı böyle hatalar yapmaz (sıklıkla). Ancak önleme, tedaviden daha iyidir - kodu, bu potansiyel hata kaynağını tamamen ortadan kaldıracak şekilde yazabiliriz. Yerleştirme karmaşıklığı artırır, bu nedenle en iyi uygulamalar, iç içe geçmeyi azaltmak için kodun yeniden düzenlenmesini önerir.

Kötü uygulama ??? Olmaz. Aslında, doğrulamaların başarısız olması durumunda en erken yöntemden dönerek doğrulamaları ele almak her zaman daha iyidir. Aksi takdirde, büyük miktarda iç içe geçmiş ifs & els ile sonuçlanır. Erken sonlandırma, kod okunabilirliğini artırır.

Ayrıca benzer bir sorudaki yanıtları kontrol edin: if-else yerine return / continue ifadesini kullanmalı mıyım?

Kötü bir uygulama değil (zaten belirtilen tüm nedenlerden dolayı). Bununla birlikte, bir yöntemde ne kadar çok getiri elde ederseniz, daha küçük mantıksal yöntemlere bölünmesi daha olasıdır.

İlk örnek bir koruma ifadesi kullanmaktır. Gönderen Vikipedi :

Bilgisayar programlamasında, bir koruma, program yürütmesinin söz konusu dalda devam etmesi için doğru olarak değerlendirilmesi gereken bir mantıksal ifadedir.

Bir yöntemin tepesinde bir grup korumaya sahip olmanın, programlamanın tamamen anlaşılabilir bir yolu olduğunu düşünüyorum. Temelde "bunlardan herhangi biri doğruysa bu yöntemi çalıştırmayın" diyor.

Yani genel olarak şuna benzer:

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

Bence bu çok daha okunaklı:

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

Performans kesintisi yoktur, ancak ikinci kod parçası daha okunabilir ve dolayısıyla bakımı daha kolaydır.

Bu durumda, ikinci örneğiniz daha iyi koddur, ancak bunun bir void işlevinden geri dönmeyle ilgisi yoktur, bunun nedeni ikinci kodun daha doğrudan olmasıdır. Ancak bir boşluk işlevinden dönmek tamamen iyidir.

Tamamen sorun değil ve 'performans cezası' yok, ancak parantez olmadan asla bir 'eğer' ifadesi yazmayın.

Her zaman

if( foo ){
    return;
}

Çok daha okunaklı; ve asla yanlışlıkla kodun bazı kısımlarının o ifadenin içinde olduğunu varsaymazsınız.

Bu konuda siz genç kancıkçılara katılmayacağım.

Geri dönüşü bir yöntemin ortasında kullanmak, geçersiz veya başka türlü, neredeyse kırk yıl önce, son derece açık bir şekilde ifade edilen nedenlerden dolayı, çok kötü bir uygulamadır, merhum Edsger W. "ve devam ediyor" Structured Programming ", Dahl, Dijkstra ve Hoare tarafından.

Temel kural, her kontrol yapısının ve her modülün tam olarak bir giriş ve bir çıkışa sahip olmasıdır. Modülün ortasındaki açık bir geri dönüş, bu kuralı bozar ve programın durumu hakkında akıl yürütmeyi çok daha zorlaştırır, bu da programın doğru olup olmadığını söylemeyi çok daha zor hale getirir (bu çok daha güçlü bir özelliktir) "işe yarıyor gibi görünüp görünmemesinden").

"GOTO İfadesi Zararlı Olarak Kabul Edildi" ve "Yapılandırılmış Programlama" 1970'lerin "Yapılandırılmış Programlama" devrimini başlattı. Bu iki parça, if-then-else, while-do ve günümüzdeki diğer açık kontrol yapılarına sahip olmamızın ve neden yüksek seviyeli dillerdeki GOTO ifadelerinin Tehlike Altındaki Türler listesinde yer almasının nedenleridir. (Benim kişisel görüşüm, Soyu Tükenmiş Türler listesinde olmaları gerektiği yönünde.)

Şunu da belirtmek gerekir ki, ilk denemede HİÇ sapma, feragat veya "evet, ama" laf kalabalığı olmaksızın kabul testini geçen ilk askeri yazılım parçası olan Mesaj Akış Modülatörünün bile olmayan bir dilde yazıldığını belirtmek gerekir. GOTO beyanı.

Ayrıca Nicklaus Wirth'in Oberon programlama dilinin en son sürümü olan Oberon-07'deki RETURN ifadesinin anlamını değiştirdiğini ve onu bir daktilo edilmiş prosedürün (yani işlev) bildiriminin son parçası haline getirdiğini belirtmek gerekir. işlevin gövdesinde çalıştırılabilir ifade. Değişikliğe ilişkin açıklaması, bunu tam olarak, önceki formun Yapılandırılmış Programlamanın tek çıkış ilkesinin ihlali OLDUĞU için yaptığını söyledi .

Koruyucuları kullanırken okuyucuların kafasını karıştırmamak için belirli kurallara uyduğunuzdan emin olun.

• işlev bir şey yapar
• korumalar yalnızca işlevdeki ilk mantık olarak tanıtıldı
• iç içe olmayan kısım, fonksiyonun temel amacını içerir

Misal

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

Nesne boş vb. Olduğunda hiçbir şey döndürmek yerine istisna atın.

Yönteminiz nesnenin boş olmamasını bekler ve durum böyle değildir, bu nedenle istisna atmalı ve arayanın bunu işlemesine izin vermelisiniz.

Ancak erken dönüş, aksi takdirde kötü bir uygulama değildir.