다른 경우를 처리하는 우아한 방법

이것은 사소한 문제이지만, 이런 식으로 코딩해야 할 때마다 반복이 귀찮게하지만 솔루션 중 어느 것이 나쁘지 않은지 확실하지 않습니다.

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

• 이런 종류의 논리에 대한 이름이 있습니까?
• 나는 너무 OCD인가?

호기심을 위해서만 악의적 인 코드 제안에 개방적입니다 ...

함수 (방법)를 분리하고 return명령문을 사용하도록 추출하십시오 .

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

DefaultAction();

또는 컨텐츠와 처리를 분리하여 분리하는 것이 좋습니다.

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();

Upd :

예외 OpenFile가 아닌 이유, IO 예외가 발생하지 않는 이유 :
파일 IO에 대한 질문이 아니라 실제로 일반적인 질문이라고 생각합니다. 같은 이름은 FileExists, OpenFile복잡 할 수 있지만, 그들을 대체 할 경우 Foo, Bar등, -이 명확 할 것 DefaultAction같은 자주 호출 할 수 있습니다 DoSomething이 아닌 예외적 인 경우가 될 수 있도록. Péter Török은 답변 이 끝날 때 이에 대해 썼습니다

두 번째 변형에 삼항 조건 연산자가있는 이유 :
[C ++] 태그가 있으면 조건 부분에 if선언이 contents있는 명령문을 작성 했습니다.

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

그러나 다른 (C와 같은) 언어의 경우 if(contents) ...; else ...;삼항 조건 연산자가있는 표현식 문과 정확히 동일하지만 더 길다. 코드의 주요 부분은 get_contents함수 였기 때문에 더 짧은 버전을 사용했습니다 (그리고 생략 된 contents유형). 어쨌든, 그것은이 질문을 넘어선 것입니다.

사용하는 프로그래밍 언어가 (0) 단락 이진 비교 (즉, false를 반환 SomeTest하면 호출하지 않는 경우 FileExists) 및 (1) 할당이 값을 반환하면 (결과 OpenFile가 할당 된 contents다음 해당 값이 인수로 전달됨) to SomeTest), 다음과 같은 것을 사용할 수는 있지만 여전히 단일 코드 =가 의도적 이라는 점을 지적하면서 코드에 의견을 제시하는 것이 좋습니다 .

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

if의 복잡성에 따라 플래그 변수 ( DefaultAction이 경우 오류를 처리하는 코드로 성공 / 실패 조건 테스트를 분리)를 사용하는 것이 좋습니다.

DefaultAction에 대한 호출을 반복하는 것보다 더 심각한 것은 코드가 직교하지 않기 때문에 스타일 자체입니다 ( 직교 적으로 작성해야하는 좋은 이유는 이 답변 참조 ).

비 직교 코드가 나쁜 이유를 보여주기 위해 네트워크 디스크에 저장된 경우 파일을 열지 않아야하는 새로운 요구 사항이 소개 될 때 원래 예를 고려하십시오. 그러면 코드를 다음과 같이 업데이트 할 수 있습니다.

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

그러나 2Gb 이상으로 큰 파일을 열지 않아야한다는 요구 사항도 있습니다. 글쎄, 우리는 다시 업데이트 :

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();
}

이러한 코드 스타일은 유지 관리에 큰 어려움이 될 것입니다.

여기에 올바르게 직교로 작성된 답변 중 Abyx의 두 번째 예 와 Jan Hudec의 답변 이 반복되지 않으므로 해당 답변에 두 가지 요구 사항을 추가하면

if(! LessThan2Gb(file))
    return null;

if(OnNetworkDisk(file))
    return null;

(또는 goto notexists;대신 return null;) 추가 된 행 이외의 다른 코드에는 영향을 미치지 않습니다 . 예를 들어 직교.

테스트 할 때 일반적인 규칙은 일반적인 경우가 아니라 예외 를 테스트 해야합니다 .

명백하게:

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

당신은 당신이 악한 해결책에도 열려 있다고 말 했으니 악한 고토를 사용하십시오.

실제로 상황에 따라이 솔루션은 악의적 인 행동을 두 번하거나 악의적 인 추가 변수보다 덜 악할 수 있습니다. 긴 함수의 중간에 (적어도 중간에 리턴으로 인해) 확실하지 않기 때문에 함수에 래핑했습니다. 그러나 긴 기능보다 OK, 기간은 아닙니다.

예외가있을 때, 특히 OpenFile 및 DoSomething이 조건이 충족되지 않으면 예외를 던질 수 있으므로 예외를 쉽게 읽을 수 있으므로 명시적인 검사가 필요하지 않습니다. 반면에 C ++에서 Java 및 C #에서 예외를 발생시키는 작업은 느리게 수행되므로 성능면에서 goto가 여전히 바람직합니다.

"악"에 대한 참고 사항 : C ++ FAQ 6.15 는 "악"을 다음과 같이 정의합니다.

그것은 그런 것을 의미 하며 그런 것은 대부분 피해야 하는 것이지만 항상 피해야 하는 것은 아닙니다 . 예를 들어, "악한 대안 중에서 가장 악한 것이 가장 적을 때마다" "악한"것을 사용하게됩니다.

그리고 그것은 goto이 맥락에서 적용됩니다 . 구조화 된 흐름 제어 구조는 대부분 더 낫지 만 조건에 할당하거나 약 3 레벨 이상 깊이 중첩, 코드 중복 또는 긴 조건과 같이 너무 많은 자체 악을 축적하는 상황에 처하면 goto단순히 끝날 수 있습니다 덜 악한 것.

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

...

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

한 가지 가능성 :

boolean handled = false;

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

물론 이것은 다른 방식으로 코드를 약간 더 복잡하게 만듭니다. 스타일 문제입니다.

다른 접근법은 예외를 사용하는 것입니다. 예 :

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...
}

이것은 더 단순 해 보이지만 다음 경우에만 해당됩니다.

• 우리는 어떤 종류의 예외를 예상 DefaultAction()하고 각각에 맞는지 정확하게 알고 있습니다.
• 파일 처리가 성공할 것으로 예상되며 누락 된 파일 또는 실패 SomeTest()는 분명히 잘못된 조건이므로 예외를 처리하는 것이 적합합니다.

이것은 더 높은 수준의 추상화입니다.

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

그리고 이것은 세부 사항을 채 웁니다.

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

함수는 한 가지 일을해야합니다. 그들은 잘해야합니다. 그들은 그것을해야합니다.
— 깨끗한 코드의 Robert Martin

어떤 사람들은 그 접근 방식이 약간 극단적 인 것을 알고 있지만 매우 깨끗합니다. 파이썬으로 설명해 드리겠습니다.

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)

그는 기능이 한 가지를해야한다고 말하면 한 가지 를 의미 합니다. processFile()테스트 결과에 따라 작업을 선택하면 그게 전부입니다. fileMeetsTest()테스트의 모든 조건을 결합한 것이 전부입니다. contentsTest()첫 번째 줄을로 전송하면 firstLineTest()그게 전부입니다.

많은 기능처럼 보이지만 실제로는 영어와 거의 같습니다.

파일을 처리하려면 파일이 테스트를 충족하는지 확인하십시오. 그렇다면, 무언가를하십시오. 그렇지 않으면 기본 조치를 수행하십시오. 파일이 있으면 테스트를 충족하고 내용 테스트를 통과합니다. 내용을 테스트하려면 파일을 열고 첫 번째 줄을 테스트하십시오. 첫 번째 줄에 대한 테스트 ...

물론, 조금 말도 안되지만, 관리자가 세부 사항에 신경 쓰지 않으면 코드의 4 줄만 읽은 후에도 읽기를 중단 할 수 있으며 processFile()여전히 기능에 대한 높은 수준의 지식을 갖습니다.

이것이 호출되는 것과 관련하여 더 많은 요구 사항을 처리하기 위해 코드가 커짐에 따라 화살촉 안티 패턴 으로 쉽게 발전 할 수 있습니다 ( https://softwareengineering.stackexchange.com/a/122625/33922에 제공된 답변에 나와 있음 ) 그런 다음 화살표와 유사한 중첩 된 조건문이있는 코드의 거대한 섹션을 갖는 함정에 빠지게됩니다.

다음과 같은 링크를 참조하십시오.

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에서 찾을 수있는 이것과 다른 안티 패턴에 대해서는 더 많은 것이 있습니다.

Jeff가 자신의 블로그에서 이와 관련하여 제공하는 유용한 팁은 다음과 같습니다.

1) 조건을 보호구로 대체하십시오.

2) 조건부 블록을 별도의 기능으로 분해합니다.

3) 부정 체크를 긍정적 체크로 변환

4) 항상 가능한 빨리 기능적으로 복귀하십시오.

Jeff McConnells의 초기 수익 제안에 관한 Jeff의 블로그 의견도 참조하십시오.

"가독성을 향상시킬 때 리턴을 사용하십시오. 특정 루틴에서는 일단 응답을 알고 있으면 즉시 호출 루틴으로 리턴하려고합니다. 루틴이 추가 정리가 필요하지 않은 방식으로 정의 된 경우 루틴 오류를 감지하고 즉시 반환하지 않으면 더 많은 코드를 작성해야합니다. "

...

"각 루틴의 반품 횟수를 최소화하십시오. 맨 아래에서 읽을 때 루틴을 이해하기가 더 어려워서 어딘가에 리턴 될 가능성을 알지 못합니다. 이러한 이유로, 개선 된 경우에만 신중하게 리턴을 사용하십시오. 가독성. "

나는 15 년 전 제가 배운 내용 때문에 항상 기능 당 1 개의 출입 통제 이론을 구독했습니다. 나는 이것이 코드를 훨씬 쉽게 읽을 수있게하고 유지 관리가 더 쉽다고 생각합니다.

이것은 DRY, nogoto 및 no-multiple-returns 규칙을 준수하며 내 의견으로는 확장 가능하고 읽을 수 있습니다.

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

별도의 방법으로 추출한 다음 :

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

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

DoSomething(contents);

또한 허용

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

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

DoSomething(contents);
return Result.Success;            

그런 다음 DefaultAction호출을 제거 DefaultAction하고 호출자를 위해 실행을 남길 수 있습니다 .

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의 접근 방식 도 좋아 합니다.

이 특별한 경우에 대한 대답은 충분히 쉽습니다 ...

FileExists와 사이에 경쟁 조건이 있습니다 OpenFile. 파일을 제거하면 어떻게됩니까?

이 특별한 경우를 처리하는 유일한 방법은 건너 뛰는 것입니다 FileExists.

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

이 깔끔하게 이러한 문제를 해결 하고 코드 청소기를합니다.

일반적으로 : 문제를 다시 생각하고 문제를 완전히 피하는 다른 솔루션을 고안하십시오.

너무 많은 다른 사람을보고 싶어하지 않을 경우 또 다른 가능성의 사용을 드롭하는 것입니다 다른 사람을 모두와 여분의 return 문에 던져. 그렇지 않으면 두 가지 이상의 조치 가능성이 있는지 판별하기 위해 더 복잡한 논리가 필요하지 않는 한 불필요합니다.

따라서 귀하의 예는 다음과 같습니다.

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);
}

개인적으로 나는 else 절을 사용하여 논리가 어떻게 작동 해야하는지 명시 적으로 언급 하지 않으므로 코드의 가독성을 향상시킵니다. 그러나 일부 코드 미화 도구 는 중첩 논리를 억제 하기 위해 단일 if 문으로 단순화하는 것을 선호합니다 .

샘플 코드에 표시된 사례는 일반적으로 단일 if문 으로 축소 될 수 있습니다 . 많은 시스템에서 파일 열기 기능은 파일이 없으면 유효하지 않은 값을 반환합니다. 때로는 이것이 기본 동작입니다. 다른 경우에는 인수를 통해 지정해야합니다. 이는 FileExists테스트가 중단 될 수 있음을 의미하며 , 존재 테스트와 파일 열기 간의 파일 삭제로 인한 경쟁 조건에 도움이 될 수 있습니다.

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

파일 존재 테스트를 제거하는 것이 추상화 레벨 분리와 호환되지 않지만, 추상화 할 수없는 여러 테스트 문제를 완전히 회피하는 추상화 레벨 혼합 문제를 직접적으로 다루지는 않습니다. 유효하지 않은 파일 핸들이 "false"에 해당하고 파일 핸들이 범위를 벗어나면 닫힙니다.

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

...

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

그러나 frozenkoi와 동의하지만 C #의 경우 TryParse 메서드의 구문을 따르는 것이 도움이 될 것이라고 생각했습니다.

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;
}

단일 기능으로 너무 많은 일을하기 때문에 코드가보기 흉하다 파일을 처리하거나 기본 조치를 취하려면 다음과 같이 시작하십시오.

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

펄과 루비 프로그래머들은 processFile(file) || defaultAction()

이제 ProcessFile을 작성하십시오.

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

물론 이와 같은 시나리오에서만 지금까지 갈 수 있지만 다음과 같은 방법이 있습니다.

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

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

추가 필터가 필요할 수 있습니다. 그런 다음이 작업을 수행하십시오.

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();

이것은 또한 의미가있을 수 있습니다.

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

어느 것이 최고입니까? 그것은 당신이 직면하고 있는 실제 문제 에 달려 있습니다.
그러나 제거해야 할 것은 구성과 다형성으로 많은 것을 할 수 있다는 것입니다.

명백한 문제

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

나에게 꽤 표준적인 것 같아? 많은 작은 일들이 일어나야하는 그런 종류의 큰 절차에 대해서는, 실패가 후자를 막을 것입니다. 그것이 옵션이라면 예외는 조금 더 깨끗합니다.

나는 이것이 오래된 질문이라는 것을 알고 있지만 언급되지 않은 패턴을 발견했다. 주로 변수를 설정하여 나중에 호출하려는 메소드를 결정합니다 (if ... else ... 외부).

이것은 코드 작업을 더 쉽게하기 위해 살펴볼 또 다른 각도입니다. 또한 호출 할 다른 메소드를 추가하거나 특정 상황에서 호출해야하는 적절한 메소드를 변경하려는 경우도 있습니다.

메소드의 모든 언급을 대체하지 않고 (아마도 일부 시나리오가 누락 될 수 있음), 모두 if ... else ... 블록의 끝에 나열되며 읽고 변경하기가 더 쉽습니다. 예를 들어 여러 메소드가 호출 될 수 있지만 중첩 된 if ... else ...에서 메소드가 여러 일치로 호출 될 수있을 때 이것을 사용하는 경향이 있습니다.

상태를 정의하는 변수를 설정하면 깊이 중첩 된 옵션이 많이있을 수 있으며 무언가를 수행하거나 수행하지 않을 때 상태를 업데이트 할 수 있습니다.

이것은 'DoSomething'이 발생했는지 확인하는 질문의 예에서와 같이 사용할 수 있으며 그렇지 않은 경우 기본 조치를 수행합니다. 또는 호출 할 수있는 각 메소드의 상태를 가질 수 있으며 해당되는 경우 설정 한 다음 if ... else ...

중첩 된 if ... else ... 문의 끝에 상태를 점검하고 그에 따라 조치를 취하십시오. 즉, 적용해야하는 모든 위치 대신 메소드에 대한 언급이 하나만 필요합니다.

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
}

중첩 된 IF를 줄이려면

1 / 조기 반품;

2 / 복합 표현 (단락 인식)

따라서 예제는 다음과 같이 리팩토링 될 수 있습니다.

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

나는 "return"을 사용하는 많은 예제를 보았지만 때로는 새로운 함수 생성을 피하고 대신 루프를 사용하고 싶습니다.

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

줄 수를 줄이거 나 무한 루프를 싫어하는 경우 루프 유형을 "do ... while (0)"으로 변경하고 마지막 "break"를 피할 수 있습니다.

이 솔루션은 어떻습니까?

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

OpenFile이 포인터를 반환한다고 가정했지만 반환 할 수없는 기본값 (오류 코드 또는 이와 유사한 것)을 지정하여 값 유형 반환과 함께 작동 할 수도 있습니다.

물론 NULL 포인터에서 SomeTest 메소드를 통해 가능한 조치를 기대하지는 않지만 (아직 알 수 없음) SomeTest (contents) 호출에 대한 NULL 포인터에 대한 추가 검사로 볼 수도 있습니다.

가장 우아하고 간결한 솔루션은 전 처리기 매크로를 사용하는 것입니다.

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

다음과 같이 아름다운 코드를 작성할 수 있습니다.

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

이 기술을 자주 사용하면 자동 서식에 의존하기 어려울 수 있으며 일부 IDE에서는 잘못 가정 한 내용에 대해 약간 소리를지를 수 있습니다. 그리고 그 말이 진행됨에 따라 모든 것이 절충되지만 반복되는 코드의 악을 피하기 위해 지불하는 것은 나쁜 가격이 아니라고 생각합니다.

호기심으로 물었고 질문에 특정 언어로 태그가 지정되지 않았기 때문에 (명령어가 마음에 들었음에도 불구하고) 게으른 평가를 지원하는 언어가 완전히 다른 접근법을 허용한다는 점을 추가하는 것이 좋습니다. 이러한 언어에서는식이 필요할 때만 평가되므로 "변수"를 정의하고 의미가있는 경우에만 사용할 수 있습니다. 예를 들어, 게으른 let/ in구조 가있는 가상의 언어에서는 흐름 제어를 잊어 버리고 다음과 같이 씁니다.

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