วิธีการที่สง่างามในการจัดการถ้า (ถ้ามี) อย่างอื่น

นี่เป็นอาการง่อยเล็กน้อย แต่ทุกครั้งที่ฉันต้องเขียนโค้ดแบบนี้การทำซ้ำจะทำให้ฉันรำคาญใจ แต่ฉันไม่แน่ใจว่าวิธีแก้ปัญหาใด ๆ จะไม่แย่ลง

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éterTörökเขียนเกี่ยวกับเรื่องนี้ในตอนท้ายของคำตอบของเขา

เหตุใดจึงมีโอเปอเรเตอร์ที่มีเงื่อนไขในตัวแปรที่สอง:
หากจะมีแท็ก [C ++] ฉันจะเขียนifข้อความที่มีการประกาศcontentsในส่วนของเงื่อนไข:

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

แต่สำหรับภาษาอื่น ๆ (เช่น C) if(contents) ...; else ...;เหมือนกับคำสั่ง expression กับตัวดำเนินการเงื่อนไขที่ประกอบไปด้วยสามส่วน แต่นานกว่านั้น เนื่องจากส่วนหลักของรหัสคือget_contentsฟังก์ชั่นฉันเพิ่งใช้รุ่นที่สั้นกว่า (และcontentsประเภทที่ละเว้น) อย่างไรก็ตามมันเกินกว่าคำถามนี้

หากภาษาโปรแกรมที่คุณใช้ (0) การเปรียบเทียบแบบไบนารีวงจรสั้น (เช่นถ้าไม่โทรSomeTestถ้าFileExistsคืนเท็จ) และ (1) การมอบหมายส่งคืนค่า (ผลลัพธ์ของการOpenFileกำหนดให้contentsแล้วค่านั้นจะถูกส่งเป็นอาร์กิวเมนต์ ถึงSomeTest) คุณสามารถใช้สิ่งต่อไปนี้ได้ แต่ก็ควรที่จะให้คุณแสดงความคิดเห็นต่อโค้ดโดยสังเกตว่าซิงเกิ้ล=นั้นมีเจตนา

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

ทั้งนี้ขึ้นอยู่กับวิธีการที่ซับซ้อนถ้ามันอาจจะดีกว่าที่จะมีตัวแปรธง (ซึ่งแยกการทดสอบเงื่อนไขความสำเร็จ / ความล้มเหลวด้วยรหัสที่จัดการข้อผิดพลาด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();
}

ควรชัดเจนว่ารูปแบบรหัสดังกล่าวจะเป็นปัญหาในการบำรุงรักษาอย่างมาก

ในบรรดาคำตอบที่นี่ซึ่งเขียนอย่างถูกต้อง orthogonally เป็นตัวอย่างที่สองของ 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();
}

คุณบอกว่าคุณเปิดกว้างถึงการแก้ปัญหาความชั่วดังนั้นใช้การนับ goto ชั่วร้ายใช่ไหม?

ในความเป็นจริงขึ้นอยู่กับบริบทการแก้ปัญหานี้อาจเป็นความชั่วร้ายน้อยกว่าความชั่วร้ายที่กระทำการสองครั้งหรือตัวแปรเสริมชั่วร้าย ฉันห่อมันไว้ในฟังก์ชั่นเพราะมันจะไม่เป็นที่แน่นอนในช่วงกลางของฟังก์ชั่นยาว (ไม่น้อยเนื่องจากการกลับมาอยู่ตรงกลาง) แต่ฟังก์ชั่นที่ยาวนานไม่ได้เป็นระยะเวลา

เมื่อคุณมีข้อยกเว้นพวกเขาจะอ่านง่ายขึ้นโดยเฉพาะถ้าคุณมี OpenFile และ DoSomething เพียงแค่โยนข้อยกเว้นหากเงื่อนไขไม่เป็นที่พอใจดังนั้นคุณไม่จำเป็นต้องตรวจสอบอย่างชัดเจนเลย ในทางกลับกันใน C ++, การโยน Java และ C # ข้อยกเว้นเป็นการดำเนินการช้าดังนั้นจากจุดประสิทธิภาพ, goto ยังคงดีกว่า

หมายเหตุเกี่ยวกับ "evil": C ++ FAQ 6.15กำหนด "evil" เป็น:

มันหมายถึงสิ่งนั้นและเป็นสิ่งที่คุณควรหลีกเลี่ยงส่วนใหญ่แต่ไม่ใช่สิ่งที่คุณควรหลีกเลี่ยงตลอดเวลา ตัวอย่างเช่นคุณจะจบลงด้วยการใช้สิ่งที่ "ชั่วร้าย" เหล่านี้เมื่อใดก็ตามที่พวกเขาเป็น "ความชั่วร้ายน้อยที่สุดของทางเลือกที่ชั่วร้าย"

และที่ใช้กับ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 ในClean Code

บางคนพบว่าวิธีการนี้รุนแรงน้อย แต่ก็สะอาดมาก อนุญาตให้ฉันแสดงใน Python:

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) ฉวยโอกาสกลับมาโดยเร็วที่สุดจากฟังก์ชั่น

ดูความคิดเห็นบางส่วนในบล็อกของเจฟฟ์เกี่ยวกับคำแนะนำของ Steve McConnells เกี่ยวกับผลตอบแทนก่อน

"ใช้การส่งคืนเมื่อเพิ่มความสามารถในการอ่าน: ในกิจวัตรบางอย่างเมื่อคุณรู้คำตอบคุณต้องการกลับไปที่รูทีนการเรียกทันทีถ้ารูทีนถูกกำหนดในลักษณะที่ไม่ต้องล้างข้อมูลเพิ่มเติมอีก ตรวจพบข้อผิดพลาดการไม่ส่งคืนทันทีหมายความว่าคุณต้องเขียนโค้ดเพิ่มเติม "

...

"ลดจำนวนการส่งคืนในแต่ละรูทีน: มันยากที่จะเข้าใจรูทีนเมื่ออ่านที่ด้านล่างคุณไม่ทราบถึงความเป็นไปได้ที่จะส่งคืนที่ใดที่หนึ่งไปข้างหน้าด้วยเหตุผลดังกล่าวให้ใช้ผลตอบแทนอย่างรอบคอบ ความสามารถในการอ่าน "

ฉันสมัครสมาชิก 1 รายการ / ออกต่อทฤษฎีการทำงานเนื่องจากสิ่งที่ฉันได้รับการสอน 15 ปีหรือมากกว่านั้น ฉันรู้สึกว่านี่ทำให้การอ่านโค้ดง่ายขึ้นมากและเมื่อคุณพูดถึงการบำรุงรักษามากขึ้น

สิ่งนี้สอดคล้องกับกฎ DRY, no-goto และ no-multiple-return กฎสามารถปรับขนาดและอ่านได้ในความคิดของฉัน:

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

วิธีนี้จะช่วยแก้ปัญหานี้ได้อย่างเรียบร้อยและทำให้โค้ดสะอาดขึ้น

โดยทั่วไป: ลองคิดทบทวนปัญหาใหม่อีกครั้งและคิดวิธีแก้ไขปัญหาอื่นที่หลีกเลี่ยงปัญหาทั้งหมด

ความเป็นไปได้อีกอย่างหนึ่งถ้าคุณไม่ต้องการเห็นคนอื่นมากเกินไปก็คือการเลิกใช้อย่างอื่นโดยสิ้นเชิง อื่นนั้นเป็นสิ่งที่ไม่จำเป็นเว้นแต่คุณจะต้องใช้ตรรกะที่ซับซ้อนกว่านี้เพื่อพิจารณาว่ามีความเป็นไปได้มากกว่าสองอย่างในการดำเนินการ

ดังนั้นตัวอย่างของคุณอาจกลายเป็น:

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

โดยส่วนตัวแล้วฉันไม่รังเกียจที่จะใช้ประโยคอื่นเนื่องจากมันระบุวิธีการทำงานของตรรกะอย่างชัดเจนและปรับปรุงการอ่านรหัสของคุณ เครื่องมือตกแต่งโค้ดบางประเภทต้องการให้ง่ายขึ้นหากคำสั่งเพื่อลดทอนตรรกะการซ้อน

เคสที่แสดงในโค้ดตัวอย่างสามารถลดลงเป็น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 # anyways ฉันคิดว่ามันจะช่วยในการติดตามไวยากรณ์ของวิธี 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(); 
}

โปรแกรมเมอร์ Perl และ Ruby เขียน 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);

ดูเหมือนว่าเป็นมาตรฐานที่ดีสำหรับฉัน สำหรับขั้นตอนใหญ่ ๆ ที่ต้องเกิดเรื่องเล็ก ๆ น้อย ๆ ความล้มเหลวใด ๆ ที่จะป้องกันไม่ให้สิ่งหลัง ข้อยกเว้นทำให้ทำความสะอาดได้เล็กน้อยหากเป็นตัวเลือก

ฉันคิดว่านี่เป็นคำถามเก่า แต่ฉันสังเกตเห็นรูปแบบที่ไม่ได้กล่าวถึง ส่วนใหญ่การตั้งค่าตัวแปรเพื่อกำหนดวิธีการ / s ที่คุณต้องการโทรหาในภายหลัง (นอก if ... else ... )

นี่เป็นอีกมุมมองหนึ่งที่จะทำให้การทำงานกับโค้ดง่ายขึ้น นอกจากนี้ยังช่วยให้เมื่อคุณอาจต้องการเพิ่มวิธีการอื่นที่จะเรียกหรือเปลี่ยนวิธีการที่เหมาะสมที่จำเป็นต้องมีการเรียกในบางสถานการณ์

แทนที่จะต้องแทนที่วิธีการทั้งหมดที่กล่าวถึง (และอาจหายไปในบางสถานการณ์) พวกเขาทั้งหมดจะถูกระบุไว้ในตอนท้ายของ ... if ... else ... block และง่ายต่อการอ่านและแก้ไข ฉันมักจะใช้สิ่งนี้เมื่อยกตัวอย่างหลายวิธีอาจถูกเรียกใช้ แต่ภายในซ้อนกันถ้า ... else ... วิธีการอาจถูกเรียกใช้ในการแข่งขันหลายครั้ง

หากคุณตั้งค่าตัวแปรที่กำหนดสถานะคุณอาจมีตัวเลือกที่ซ้อนกันจำนวนมากและปรับปรุงสถานะเมื่อต้องดำเนินการบางอย่าง (หรือไม่ให้ทำ)

สิ่งนี้สามารถใช้งานได้ในตัวอย่างที่ถามในคำถามที่เรากำลังตรวจสอบว่า 'DoSomething' เกิดขึ้นหรือไม่และหากไม่ดำเนินการตามค่าเริ่มต้น หรือคุณอาจมีสถานะสำหรับแต่ละวิธีที่คุณอาจต้องการโทรตั้งค่าเมื่อใช้งานได้แล้วเรียกใช้วิธีการที่เหมาะสมนอกถ้า ... ...

ในตอนท้ายของคำสั่งซ้อนถ้า ... 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;
}

หากคุณต้องการที่จะเขียนเส้นน้อยลงหรือคุณเกลียดลูปไม่มีที่สิ้นสุดเป็นฉันคุณสามารถเปลี่ยนประเภทวงเป็น "ทำ ... ในขณะที่ (0)" และหลีกเลี่ยงการ "หยุด" ล่าสุด

วิธีการแก้ปัญหานี้:

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

ฉันตั้งสมมติฐานว่า OpenFile จะส่งกลับตัวชี้ แต่สิ่งนี้สามารถทำงานกับการส่งคืนชนิดของค่าโดยการระบุค่าเริ่มต้นบางอย่างที่ไม่สามารถส่งคืนได้ (รหัสข้อผิดพลาดหรือบางอย่างเช่นนั้น)

แน่นอนว่าฉันไม่ได้คาดหวังว่าจะมีการกระทำที่เป็นไปได้ด้วยวิธี SomeTest บนตัวชี้ NULL (แต่คุณไม่เคยรู้) ดังนั้นสิ่งนี้อาจถูกมองว่าเป็นการตรวจสอบเพิ่มเติมสำหรับตัวชี้ NULL สำหรับการโทร SomeTest (เนื้อหา)

เห็นได้ชัดว่าโซลูชั่นที่หรูหราและรัดกุมที่สุดคือการใช้มาโครตัวประมวลผลล่วงหน้า

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