Bu ifadelere gitmeyi haklı çıkarıyor mu?

Bu soruya bir saniye önce rastladım ve malzemenin bir kısmını oradan çıkarıyorum: 'break n' yapısı için bir isim var mı?

Bu, insanların programa çift iç içe bir döngüden çıkma talimatı vermeleri için gereksiz derecede karmaşık bir yol gibi görünüyor:

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

Ders kitaplarının goto ifadelerinin şeytan olduğunu söylemeyi sevdiğini biliyorum ve bunlara hiç düşkün değilim, ama bu kuralın bir istisnasını haklı çıkarıyor mu?

Döngüler için n-nested ile ilgili cevaplar arıyorum.

NOT: İster tamamen dar görüşlü cevaplar, aradaki evet, hayır veya bir yere cevap yok edilir. Özellikle cevap hayır ise, o zaman iyi ve meşru bir neden belirtin (bu zaten Stack Exchange düzenlemelerinden çok uzak değildir).

Bir go-to ifadesine görünen ihtiyaç , döngüler için kötü koşullu ifadeler seçmenizden kaynaklanır .

Dış halkanın uzun süre devam etmesini i < 10ve en içteki halkanın da uzun süre devam etmesini istediğinizi belirtiyorsunuz j > 0.

Ama gerçekte istediğiniz bu değil, döngülere değerlendirmelerini istediğiniz gerçek durumu söylemediniz, sonra mola veya git kullanarak çözmek istiyorsunuz.

Döngülere başlamak için gerçek niyetlerinizi söylerseniz, molalara veya gitmeye gerek yoktur.

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

Bu durumda, kodu ayrı bir rutine ve sonra da yalnızca returniç döngüden yeniden düzenleyebilirsiniz . Bu, dış döngüden kopma ihtiyacını ortadan kaldıracaktır:

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

Hayır, a'nın gotogerekli olduğunu düşünmüyorum . Bu şekilde yazarsanız:

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

Her &&!brokeniki döngüye de sahip olduğunuzda , her iki döngüden de kurtulmanızı sağlar i==j.

Bana göre bu yaklaşım tercih edilir. Döngü koşulları son derece açıktır: i<10 && !broken.

Çalışan bir sürüm burada görülebilir: http://rextester.com/KFMH48414

Kod:

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

Çıktı:

i == j == 1 olduğunda döngü kesiliyor
2
0

Kısa cevap "duruma bağlıdır". Kodunuzun okunabilirliği ve anlaşılırlığı konusunda seçim yapmayı savunuyorum. Goto yolu, durumu düzeltmekten daha okunaklı olabilir veya tersi de olabilir. En az sürpriz ilkesini, mağazada / projede kullanılan kılavuzu ve kod tabanının tutarlılığını da göz önünde bulundurabilirsiniz. Örneğin, anahtarı bırakmaya veya hata işleme için Linux çekirdeği kod tabanında yaygın bir uygulamadır. Ayrıca bazı programcıların kodunuzu okumada sorun yaşayabileceğini unutmayın (ya "goto kötüdür" mantrasıyla yükseltilmiş ya da sadece öğretmenleri öyle düşündüğü için öğrenilmemiştir) ve birkaçı "sizi yargılayabilir".

Genel olarak konuşursak, özellikle zıplama çok uzun değilse, aynı işlevde daha ileri gitmek bir goto genellikle kabul edilebilir. Yuvalanmış bir döngüden ayrılma durumunuz bilinen "o kadar kötü değil" goto örneğidir.

Sizin durumunuzda, goto cazip görünen bir iyileştirmeye yeterlidir, ancak kod tabanınızda onları kullanmaya karşı kuralı ihlal etmeye değecek bir gelişme değildir.

Gelecekteki yorumcunuzu düşünün: "Bu kişi kötü bir kodlayıcı mı yoksa bu aslında goto'nun buna değer olduğu bir durum mu? Bunu kendim için kararlaştırmak veya araştırmak için 5 dakika ayırmama izin verin. internet." Tamamen goto kullanamadığınızda neden gelecekteki kodlayıcınıza bunu yapasınız ki?

Genel olarak bu zihniyet tüm "kötü" kodlar için geçerlidir ve hatta onu tanımlar: eğer şimdi çalışıyorsa ve bu durumda iyi ise, ancak doğru olduğunu doğrulamak için çaba sarf eder, bu dönemde bir goto her zaman yapar, o zaman yapma yap.

Bununla birlikte, biraz daha dikenli durumlardan birini ürettiniz. Yapabilirsin:

• her iki döngüden kurtulmak için boole bayrağı gibi daha karmaşık kontrol yapıları kullanın
• iç döngünüzü kendi rutininin içine koyun (muhtemelen ideal)
• her iki döngüyü de rutin içine koyun ve kırmak yerine geri dönün

Bir çift döngünün o kadar tutarlı olmadığı bir durum yaratmak benim için çok zor, zaten kendi rutini olmamalı.

Bu arada, bunun en iyi tartışması Steve McConnell'in Code Complete'idir . Bu sorunları eleştirel bir şekilde düşünmekten hoşlanıyorsanız, okumasına, önemsizliğine rağmen örtbas etmenizi şiddetle tavsiye ederim.

TLD; DR: Spesifik olarak hayır, genel olarak evet

Kullandığınız spesifik örnek için, diğer birçok kişinin işaret ettiği aynı nedenlerle hayır diyebilirim. Kodu, ihtiyacını ortadan kaldıran, eşdeğer derecede iyi bir forma kolayca yeniden düzenleyebilirsiniz goto.

Genel olarak, yasaklanma goto, anlaşılan doğasına gotove onu kullanma maliyetine dayanan bir genellemedir . Yazılım mühendisliğinin bir kısmı uygulama kararları vermektir. Bu kararların gerekçelendirilmesi, maliyetin faydalara karşı tartılması ve faydaların maliyetten daha ağır basmasıyla, uygulamanın gerekçelendirilmesi ile gerçekleşir. Tartışma hem maliyet hem de fayda gibi farklı değerlemelerden kaynaklanır.

Mesele şu ki goto, a'nın haklı olduğu her zaman istisnalar olacaktır , ancak sadece bazıları için farklı değerlemeler nedeniyle. Yazık ki birçok mühendis, sadece amacı anlamaya yönelik cehalet teknikleri hariç tutuyor, çünkü nedenini anlamak için zaman ayırmak yerine internette okuyorlar.

Bu durum bir istisnayı haklı bulmuyor, çünkü bu yazılabilir:

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}