(Eğer başka) varsa başka yollarla işlemek

Bu küçük bir kıkırdama, ama böyle bir şeyi kodlamak zorunda kaldığımda tekrarlama beni rahatsız ediyor, ama çözümlerin hiçbirinin daha kötü olmadığından emin değilim.

if(FileExists(file))
{
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(SomeTest(contents))
    {
        DoSomething(contents);
    }
    else
    {
        DefaultAction();
    }
}
else
{
    DefaultAction();
}

• Bu tür bir mantık için bir isim var mı?
• Ben de biraz OKB muyum?

Kötülük kanunu önerilerine açığım, sadece merak aşkına ...

İşlev (yöntem) 'i ayıklayın ve returndeyimi kullanın :

if(FileExists(file))
{
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(SomeTest(contents))
    {
        DoSomething(contents);
        return;
    }
}

DefaultAction();

Veya, belki de daha iyisi, içerik alma ve işlemeyi ayırma

contents_t get_contents(name_t file)
{
    if(!FileExists(file))
        return null;

    contents = OpenFile(file);
    if(!SomeTest(contents)) // like IsContentsValid
        return null;

    return contents;
}

...

contents = get_contents(file)
contents ? DoSomething(contents) : DefaultAction();

gnc:

Neden istisnalar değil, neden OpenFileIO istisnası atmıyor:
Bunun, IO dosyasıyla ilgili sorudan çok genel bir soru olduğunu düşünüyorum. Gibi isimler FileExists, OpenFilekafa karıştırıcı olabilir, ancak bunların yerine eğer Foo, Barvb, - o daha net olurdu DefaultActionsıklıkta adlandırılabilir DoSomethingdışı istisnai durumda olabilir, böylece. Péter Török bu sorunun cevabının sonunda yazdı

Neden 2. varyantta üçlü koşullu işleç
var : [C ++] etiketi varsa, koşul bölümünde ifbeyanı ile ifade yazdım contents:

if(contents_t contents = get_contents(file))
    DoSomething(contents);
else
    DefaultAction();

Ancak, diğer (C-benzeri) diller için, if(contents) ...; else ...;tam şartlı operatöre sahip olan ifade ifadesiyle aynı, ancak daha uzun. Kodun ana kısmı get_contentsişlev olduğu için sadece kısa versiyonunu kullandım (ve ayrıca ihmal edilen contentstip). Neyse, bu sorunun ötesinde.

Kullandığınız programlama dili (0) kısa devreler ikili karşılaştırmalar (yani iptal etmemesi halinde ise SomeTesteğer FileExistsdöner false) ve (1) atama bir değer (sonucunu döndürür OpenFileatanan contentsbir argüman olarak ve daha sonra bu değer geçirilir için SomeTest), aşağıdaki gibi bir şey kullanabilirsiniz, ancak yine de bekarın =kasıtlı olduğunu belirten kodu yorumlamanız tavsiye edilir .

if( FileExists(file) && SomeTest(contents = OpenFile(file)) )
{
    DoSomething(contents);
}
else
{
    DefaultAction();
}

İf'in ne kadar kıvrımlı olduğuna bağlı olarak, bir bayrak değişkenine sahip olmak daha iyi olabilir (bu, başarı / başarısızlık durumlarının test edilmesini DefaultAction, bu durumda hatayı işleyen kodla ayırır )

DefaultAction çağrısının tekrarlanmasından daha ciddi olan stilin kendisidir, çünkü kod dikey değildir ( dikey yazı yazmak için iyi nedenler için bu cevaba bakınız ).

Ortogonal olmayan kodun neden kötü olduğunu göstermek için, bir ağ diskinde depolanmışsa dosyayı açmamamız gereken yeni bir gereksinim ortaya çıktığında orijinal örneği düşünün. O zaman kodu şu şekilde güncelleyebiliriz:

if(FileExists(file))
{
    if(! OnNetworkDisk(file))
    {
        contents = OpenFile(file); // <-- prevents inclusion in if
        if(SomeTest(contents))
        {
            DoSomething(contents);
        }
        else
        {
            DefaultAction();
        }
    }
    else
    {
        DefaultAction();
    }
}
else
{
    DefaultAction();
}

Ancak, aynı zamanda büyük dosyaları 2 Gb üzerinden açmamamız şartı da ortaya çıkıyor. Peki, tekrar güncelledik:

if(FileExists(file))
{
    if(LessThan2Gb(file))
    {
        if(! OnNetworkDisk(file))
        {
            contents = OpenFile(file); // <-- prevents inclusion in if
            if(SomeTest(contents))
            {
                DoSomething(contents);
            }
            else
            {
                DefaultAction();
            }
        }
        else
        {
            DefaultAction();
        }
    else
    {
        DefaultAction();
    }
}
else
{
    DefaultAction();
}

Bu kod tarzının çok büyük bir bakım ağrısı olacağı çok açık olmalıdır.

Bu yazının ortogonal olarak yazdığı cevaplar arasında Abyx'in ikinci örneği ve Jan Hudec'in cevabı var , bu yüzden tekrar etmeyeceğim, sadece bu cevaplara iki gereksinimi eklemenin sadece

if(! LessThan2Gb(file))
    return null;

if(OnNetworkDisk(file))
    return null;

(veya goto notexists;yerine return null;), eklenen satırlardan başka hiçbir kodu etkilemiyor . Ortogonal örneğin.

Test yaparken, genel kural normal durumu değil istisnaları test etmek olmalıdır .

Açıkçası:

Whatever(Arguments)
{
    if(!FileExists(file))
        goto notexists;
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(!SomeTest(contents))
        goto notexists;
    DoSomething(contents);
    return;
notexists:
    DefaultAction();
}

Kötü çözümlere bile açık olduğunuzu söylediniz, bu yüzden kötü goto sayar, değil mi?

Aslında, bağlama bağlı olarak bu çözüm, eylemi iki kez yapan kötülük veya ekstra değişken değişkenden daha az kötü olabilir. Bir işleve sarıldım, çünkü uzun işlevin ortasında kesinlikle sorun olmaz (en azından ortadaki dönüş nedeniyle). Fakat uzun süre işlev tamam değil, periyot.

İstisnalarınız olduğunda, okunması daha kolay olacaktır, özellikle de OpenFile ve DoSomething'in, koşullar yerine getirilmediği takdirde bir istisna atması durumunda, açık kontroller yapmanız gerekmez. Öte yandan, C ++ 'da Java ve C # bir istisna atmak yavaş bir işlemdir, bu nedenle performans açısından goto hala tercih edilir.

"Kötülük" ile ilgili not: C ++ SSS 6.15 , "kötülüğü" şu şekilde tanımlar:

Bu böyle bir şey demek, çoğu zaman kaçınmanız gereken bir şeydir, ancak her zaman kaçınmanız gereken bir şey değildir . Örneğin, "kötülük alternatiflerinin en kötü kötüsü" olduğunda, bu "kötülük" şeylerini kullanmanızla sonuçlanacaksınız.

Ve gotobu bağlamda geçerlidir . Yapılandırılmış akış kontrol yapıları çoğu zaman daha iyidir, ancak şartların yerine getirilmesi, yaklaşık 3 seviyeden fazla derinlemesine iç içe yerleştirilmesi, kodların kopyalanması veya uzun koşulların gotobasit bir şekilde sona ermesi gibi, kendi kötülerinden çok fazla biriktirdikleri bir duruma geldiğinizde daha az kötülük olmaktan.

function FileContentsExists(file) {
    return FileExists(file) ? OpenFile(file) : null;
}

...

contents = FileContentExists(file);
if(contents && SomeTest(contents))
{
    DoSomething(contents);
}
else
{
    DefaultAction();
}

Bir olasılık:

boolean handled = false;

if(FileExists(file))
{
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(SomeTest(contents))
    {
        DoSomething(contents);
        handled = true;
    }
}
if (!handled)
{
    DefaultAction();
}

Tabii ki, bu kodu farklı bir şekilde biraz daha karmaşık hale getirir. Bu yüzden büyük ölçüde stil bir sorudur.

Farklı bir yaklaşım istisnalar kullanıyor olabilir, örneğin:

try
{
    contents = OpenFile(file); // throws IO exception if file not found
    DoSomething(contents); // calls SomeTest() and throws exception on failure
}
catch(Exception e)
{
    DefaultAction();
    // and the exception should be at least logged...
}

Bu daha basit görünüyor, ancak yalnızca

• tam olarak ne tür istisnalar olacağını ve DefaultAction()her birine uyduğunu biliyoruz
• dosya işlemenin başarılı olmasını bekliyoruz ve eksik bir dosya ya da başarısızlık SomeTest()açıkça hatalı bir durumdur, bu nedenle üzerine bir istisna atmak uygun olur.

Bu daha yüksek bir soyutlama seviyesindedir:

if (WeCanDoSomething(file))
{
   DoSomething(contents);
}
else
{
   DefaultAction();
} 

Ve bu da detayları dolduruyor.

boolean WeCanDoSomething(file)
{
    if FileExists(file)
    {
        contents = OpenFile(file);
        return (SomeTest(contents));
    }
    else
    {
        return FALSE;
    }
}

İşlevler bir şey yapmalı. İyi yapmalılar. Sadece yapmalılar.
- Robert Martin Temiz Kodda

Bazı insanlar bu yaklaşımı biraz aşırı buluyor, ama aynı zamanda çok temiz. Python'da göstermeme izin ver:

def processFile(self):
    if self.fileMeetsTest():
        self.doSomething()
    else:
        self.defaultAction()

def fileMeetsTest(self):
    return os.path.exists(self.path) and self.contentsTest()

def contentsTest(self):
    with open(self.path) as file:
        line = file.readline()
        return self.firstLineTest(line)

Fonksiyonların bir şeyi yapması gerektiğini söylediğinde, bir şey ifade ediyor. processFile()Bir testin sonucuna dayanarak bir eylem seçer ve hepsi bu. fileMeetsTest()Testin tüm koşullarını birleştirir ve hepsi bu. contentsTest()ilk satırı transfer eder firstLineTest()ve hepsi bu.

Bir çok fonksiyona benziyor, fakat pratik olarak İngilizce'yi hemen hemen okuyor:

Dosyayı işlemek için teste uyup uymadığını kontrol edin. Eğer öyleyse, o zaman bir şeyler yap. Aksi takdirde, varsayılan işlemi yapın. Dosya varsa ve içerik testini geçerse testi karşılar. İçeriği test etmek için dosyayı açın ve ilk satırı test edin. İlk hattın testi ...

Kabul ediyorum, bu biraz endişe vericidir, ancak bir bakıcının ayrıntıları önemsemediği takdirde, sadece 4 satırlık koddan sonra okumayı durdurabileceğini processFile()ve fonksiyonun ne yaptığı hakkında hala yüksek düzeyde bilgiye sahip olacağını unutmayın.

Buna ne denirse gelsin , kodunuz daha fazla gereksinimi karşılayacak şekilde büyüdükçe ( https://softwareengineering.stackexchange.com/a/122625/33922 adresinde verilen cevapta gösterildiği gibi) daha fazla gereksinimi karşılamak için büyüdükçe ok ucu karşıtı düzende kolayca gelişebilir ve sonra bir ok gibi iç içe koşullu ifadeler ile büyük kod bölümleri olması tuzağına düşüyor.

Bağlantılara bakınız;

http://codinghorror.com/blog/2006/01/flattening-arrow-code.html

http://lostechies.com/chrismissal/2009/05/27/anti-patterns-and-worst-practices-the-arrowhead-anti-pattern/

Google’da bulunabilecek bu ve diğer anti örüntüler hakkında daha birçok şey var.

Jeff'in blogunda bu konuda sağladığı bazı harika ipuçları;

1) Koşulları koruyucu maddeler ile değiştirin.

2) Koşullu blokları ayrı fonksiyonlara ayırın.

3) Negatif kontrolleri pozitif kontrollere dönüştürün

4) Her zaman fırsatçı olarak işlevden en kısa sürede geri dönün.

Jeff'in blogunda Steve McConnells'in erken iadelerle ilgili önerileriyle ilgili bazı yorumlara bakın;

"Okunabilirliği arttırdığında bir geri dönüş kullanın: Bazı rutinlerde, cevabı öğrendikten sonra, onu hemen arayan rutine geri döndürmek istersiniz. bir hata algıladı, hemen geri dönmemek daha fazla kod yazmanız gerektiği anlamına geliyor. "

...

“Her rutinde geri dönüş sayısını en aza indirin: En alttan okuyarak, bir yere bir yere geri dönme olasılığının farkında olmadığınızda, bir rutini anlamak daha zordur. okunabilirlik. "

15 yıl veya daha uzun bir süre önce öğretildiklerim nedeniyle her bir fonksiyon teorisi için 1 giriş / çıkışa her zaman abone oldum. Bunun sadece kodu okumayı çok daha kolay hale getirdiğini ve daha fazla bahsettiğinizden bahsettiğiniz gibi hissediyorum

Bu, DRY'ye (kurallara aykırı) ve geri dönüşsüz ve geri dönüşsüz kurallara uyuyor, bence ölçeklenebilir ve okunabilir:

success = FileExists(file);
if (success)
{
    contents = OpenFile(file);
    success = SomeTest(contents);
}
if (success)
{
    DoSomething(contents);
}
else
{
    DefaultAction();
}

Bunu ayrı bir yönteme ayıklarım ve sonra:

if(!FileExists(file))
{
    DefaultAction();
    return;
}

contents = OpenFile(file);
if(!SomeTest(contents))
{
    DefaultAction();
    return;
}

DoSomething(contents);

ayrıca izin verir

if(!FileExists(file))
{
    DefaultAction();
    return Result.FileNotFound;
}

contents = OpenFile(file);
if(!SomeTest(contents))
{
    DefaultAction();
    return Result.TestFailed;
}

DoSomething(contents);
return Result.Success;            

o zaman muhtemelen DefaultActionaramaları kaldırabilir DefaultActionve arayanı yürütmeyi bırakabilirsiniz :

Result OurMethod(file)
{
    if(!FileExists(file))
    {
        return Result.FileNotFound;
    }

    contents = OpenFile(file);
    if(!SomeTest(contents))
    {
        return Result.TestFailed;
    }

    DoSomething(contents);
    return Result.Success;            
}

void Caller()
{
    // something, something...

    var result = OurMethod(file);
    // if (result == Result.FileNotFound || result == Result.TestFailed), or just
    if (result != Result.Success)        
    {
        DefaultAction();
    }
}

Jeanne Pindar'ın yaklaşımını da seviyorum .

Bu özel durum için, cevap yeterince kolaydır ...

FileExistsVe arasında bir yarış koşulu var OpenFile: dosya kaldırılırsa ne olur?

Bu özel durumla başa çıkmanın tek mantıklı yolu atlamaktır FileExists:

contents = OpenFile(file);
if (!contents) // open failed
    DefaultAction();
else (SomeTest(contents))
    DoSomething(contents);

Bu düzgünce bu sorunu çözer ve kodu daha temiz hale getirir.

Genel olarak: Sorunu yeniden düşünmeye çalışın ve sorunu tamamen önleyen başka bir çözüm geliştirin.

Çok fazla başka görmek beğenmezseniz başka olasılık kullanımını bırakmaktır başka tamamen ve ekstra getiri açıklamada atmak. İki eylemden daha fazlası olup olmadığına karar vermek için daha karmaşık bir mantık gerektirmedikçe, Else biraz gereksizdir.

Böylece örneğiniz olabilir:

void DoABunchOfStuff()
{
    if(FileExists(file))
    {
        DoSomethingWithFileContent(file);
        return;
    }

    DefaultAction();
}

void DoSomethingWithFileContent(file)
{        
    var contents = GetFileContents(file)

    if(SomeTest(contents))
    {
        DoSomething(contents);
        return;
    }

    DefaultAction();
}

AReturnType GetFileContents(file)
{
    return OpenFile(file);
}

Şahsen , mantığın nasıl çalışması gerektiğini açıkça ifade ettiği için else deyimini kullanmak sorun değil ve bu nedenle kodunuzun okunabilirliğini arttırıyor. Ancak bazı kod güzelleştirme araçları, iç içe yerleştirme mantığından vazgeçmek için tek bir if ifadesini basitleştirmeyi tercih eder .

Örnek kodda gösterilen durum genellikle tek bir ififadeye indirgenebilir . Birçok sistemde, dosya açma işlevi, dosya zaten mevcut değilse geçersiz bir değer döndürür. Bazen bu varsayılan davranıştır; Diğer zamanlarda, bir argüman ile belirtilmelidir. Bu, FileExiststestin düşebileceği anlamına gelir; bu, ayrıca varlık testi ile dosya açılması arasındaki dosya silme işleminden kaynaklanan yarış koşullarına da yardımcı olabilir.

file = OpenFile(path);
if(isValidFileHandle(file) && SomeTest(file)) {
    DoSomething(file);
} else {
    DefaultAction();
}

Bu tamamen soyutlama düzeyinde karıştırma sorununu doğrudan ele almaz, çünkü çoklu, zincirlenemeyen testler konusunu tamamen yok eder, ancak dosya mevcudiyeti testi ile uzaklaşmak soyutlama seviyelerini ayırmakla uyumlu değildir. Geçersiz dosya tanıtıcılarının "false" değerine eşdeğer olduğunu ve kapsam dışında olduklarında dosya tanıtıcılarının yakın olduğunu varsayarak:

OpenFileIfSomething(path:String) : FileHandle {
    file = OpenFile(path);
    if (file && SomeTest(file)) {
        return file;
    }
    return null;
}

...

if ((file = OpenFileIfSomething(path))) {
    DoSomething(file);
} else {
    DefaultAction();
}

Ancak, frozenkoi ile aynı fikirdeyim, yine de, C # için TryParse yöntemlerinin sözdizimini izlemenin yardımcı olacağını düşündüm.

if(FileExists(file) && TryOpenFile(file, out contents))
    DoSomething(contents);
else
    DefaultAction();

bool TryOpenFile(object file, out object contents)
{
    try{
        contents = OpenFile(file);
    }
    catch{
        //something bad happened, computer probably exploded
        return false;
    }
    return true;
}

Kodunuz çirkin çünkü tek bir fonksiyonda çok fazla şey yapıyorsunuz. Ya dosyayı işlemek ya da varsayılan eylemde bulunmak istiyorsanız, şunu söyleyerek başlayın:

if (!ProcessFile(file)) { 
  DefaultAction(); 
}

Perl ve Ruby programcıları yazmak processFile(file) || defaultAction()

Şimdi git ProcessFile yaz:

if (FileExists(file)) { 
  contents = OpenFile(file);
  if (SomeTest(contents)) {
    processContents(contents);
    return true;
  }
}
return false;

Elbette şu ana kadar böyle senaryolarda gidebilirsiniz, ancak işte size bir yol:

interface File<T> {
    function isOK():Bool;
    function getData():T;
}

var appleFile:File<Apple> = appleStorage.get(fileURI);
if (appleFile.isOK())
    eat(file.getData());
else
    cry();

Ek filtreler isteyebilirsiniz. O zaman şunu yap:

var appleFile = appleStorage.get(fileURI, isEdible);
//isEdible is of type Apple->Bool and will be used internally to answer to the isOK call
if (appleFile.isOK())
    eat(file.getData());
else
    cry();

Her ne kadar bu da bir anlam ifade etse de:

function eat(apple:Apple) {
     if (isEdible(apple)) 
         digest(apple);
     else
         die();
}
var appleFile = appleStorage.get(fileURI);
if (appleFile.isOK())
    eat(appleFile.getData());
else
    cry();

Hangisi en iyisi? Bu, karşılaştığınız gerçek dünya problemine bağlıdır .
Ama elinden alınması gereken şey: kompozisyon ve polimorfizm ile çok şey yapabilirsiniz.

Bariz olan ne yanlış

if(!FileExists(file)) {
    DefaultAction();
    return;
}
contents = OpenFile(file);
if(!SomeTest(contents))
{
    DefaultAction();
    return;
}        
DoSomething(contents);

Bana oldukça standart görünüyor? Çok sayıda küçük şeyin olması gereken bu büyük prosedür için, hiçbirinin başarısızlığı, ikincisini engelleyecekti. İstisnalar, eğer bir seçenekse, biraz daha temiz.

Bunun eski bir soru olduğunun farkındayım, ancak daha önce söylenmemiş bir kalıp fark ettim; daha sonra, çağırmak istediğiniz yöntemi / yöntemleri belirlemek için bir değişken ayarlamak (if ... else ... dışında).

Bu, kodun çalışmasını kolaylaştırmak için bakılması gereken başka bir açıdır. Ayrıca, çağrılacak başka bir yöntemi ne zaman eklemek istediğinizi veya belirli durumlarda aranması gereken uygun yöntemi değiştirmenizi de sağlar.

Yöntemin tüm sözlerini değiştirmek zorunda kalmak yerine (ve belki bazı senaryolar eksik olabilir), hepsi if ... else ... bloğunun sonunda listelenir ve okunması ve değiştirilmesi daha kolaydır. Örneğin, birkaç yöntem çağrılabildiğinde bunu kullanma eğilimindeyim, ancak iç içe geçmişse ... else ... birkaç eşleşmede bir yöntem çağrılabilir.

Durumu tanımlayan bir değişken ayarlarsanız, çok fazla iç içe geçmiş seçeneğiniz olabilir ve bir şey yapılacak (veya yapılmayacak) olduğunda durumu güncelleyebilirsiniz.

Bu, 'DoSomething' olup olmadığını kontrol ettiğimiz soruda sorulan örnekte olduğu gibi kullanılabilir ve eğer değilse, varsayılan eylemi gerçekleştirir. Veya çağırmak isteyebileceğiniz her yöntem için durumunuz olabilir, uygun olduğunda ayarlayın, ardından uygulanabilir yöntemi arayın.

İç içe geçmiş if ... else ... deyimlerinin sonunda, durumu kontrol edip buna göre davranırsınız. Bu, uygulanması gereken tüm yerler yerine yalnızca bir yöntemden bahsetmeniz gerektiği anlamına gelir.

bool ActionDone = false;

if (Method_1(object_A)) // Test 1
{
    result_A = Method_2(object_A); // Result 1

    if (Method_3(result_A)) // Test 2
    {
        Method_4(result_A); // Action 1
        ActionDone = true;
    }
}

if (!ActionDone)
{
    Method_5(); // Default Action
}

İç içe geçmiş IF'yi azaltmak için:

1 / erken dönüş;

2 / bileşik ifade (kısa devre duyarlı)

Öyleyse, örneğiniz şöyle yeniden yansıtılabilir:

if( FileExists(file) && SomeTest(contents = OpenFile(file)) )
{
    DoSomething(contents);
    return;
}
DefaultAction();

Ben de kullandığım "return" ile birçok örnek gördüm ama bazen yeni işlevler oluşturmaktan kaçınmak ve bunun yerine bir döngü kullanmak istiyorum:

while (1) {
    if (FileExists(file)) {
        contents = OpenFile(file);
        if (SomeTest(contents)) {
           DoSomething(contents);
           break;
        } 
    }
    DefaultAction();
    break;
}

Daha az satır yazmak isterseniz veya benim gibi sonsuz döngülerden nefret ediyorsanız, döngü türünü "do ... while (0)" olarak değiştirebilir ve son "kırılmayı" önleyebilirsiniz.

Peki ya bu çözüm:

content = NULL; //I presume OpenFile returns a pointer 
if(FileExists(file))
    contents = OpenFile(file);
if(content != NULL && SomeTest(contents))
    DoSomething(contents);
else
    DefaultAction();

OpenFile'nin bir işaretçi döndürdüğünü varsaydım, ancak bu, döndürülemeyen bir varsayılan değer (hata kodları veya benzeri bir şey) belirterek değer türü dönüşüyle ​​de çalışabilir.

Tabii ki NULL imlecindeki SomeTest yöntemi ile bazı olası işlemler beklemiyorum (ama asla bilemezsin), bu yüzden bu ayrıca SomeTest (içerik) çağrısı için NULL imleci için fazladan bir kontrol olarak görülebilir.

Açıkçası, en zarif ve özlü çözüm bir önişlemci makrosu kullanmaktır.

#define DOUBLE_ELSE(CODE) else { CODE } } else { CODE }

Bunun gibi güzel bir kod yazmanıza izin verir:

if(FileExists(file))
{
    contents = OpenFile(file);
    if(SomeTest(contents))
    {
        DoSomething(contents);
    }
    DOUBLE_ELSE(DefaultAction();)

Bu tekniği sık kullanırsanız otomatik biçimlendirmeye güvenmek zor olabilir ve bazı IDE'lerin hatalı bir şekilde ne tür bir hata oluştuğunu düşündüğü konusunda size biraz bağırıyor olabilir. Ve söylendiği gibi, her şey bir tradeoff, ama sanırım tekrarlanan kodun kötülüklerini önlemek için ödemek için kötü bir fiyat değil.

Siz meraktan sorduğunuzdan ve sorunuz belirli bir dille etiketlenmemiş olduğundan (zorunlu dilleri aklınızda tutturmuş olmanıza rağmen), tembel değerlendirmeyi destekleyen dillerin tamamen farklı bir yaklaşıma izin verdiğini eklemeye değer olabilir. Bu dillerde, ifadeler yalnızca gerektiğinde değerlendirilir, bu nedenle "değişkenleri" tanımlayabilir ve bunları yalnızca mantıklı geldiğinde kullanabilirsiniz. Örneğin, tembel let/ inyapıları olan kurgusal bir dilde akış kontrolünü ve yazmayı unutursunuz:

let
  contents = ReadFile(file)
in
  if FileExists(file) && SomeTest(contents) 
    DoSomething(contents)
  else 
    DefaultAction()