การใช้บล็อกขอบเขตภายในภายในฟังก์ชั่นมีสไตล์ไม่ดีหรือไม่?

มีบางกรณี (ค่อนข้างหายาก) ที่มีความเสี่ยง:

• การนำตัวแปรที่ไม่ต้องการนำมาใช้ซ้ำ (ดูตัวอย่างที่ 1)

• หรือใช้ตัวแปรแทนตัวแปรอื่นปิดความหมาย (ดูตัวอย่างที่ 2)

ตัวอย่างที่ 1:

var data = this.InitializeData();
if (this.IsConsistent(data, this.state))
{
    this.ETL.Process(data); // Alters original data in a way it couldn't be used any longer.
}

// ...

foreach (var flow in data.Flows)
{
    // This shouldn't happen: given that ETL possibly altered the contents of `data`, it is
    // not longer reliable to use `data.Flows`.
}

ตัวอย่างที่ 2:

var userSettingsFile = SettingsFiles.LoadForUser();
var appSettingsFile = SettingsFiles.LoadForApp();

if (someCondition)
{
    userSettingsFile.Destroy();
}

userSettingsFile.ParseAndApply(); // There is a mistake here: `userSettingsFile` was maybe
                                  // destroyed. It's `appSettingsFile` which should have
                                  // been used instead.

ความเสี่ยงนี้สามารถบรรเทาได้ด้วยการแนะนำขอบเขต:

ตัวอย่างที่ 1:

// There is no `foreach`, `if` or anything like this before `{`.

{
    var data = this.InitializeData();
    if (this.IsConsistent(data, this.state))
    {
        this.ETL.Process(data);
    }
}

// ...

// A few lines later, we can't use `data.Flows`, because it doesn't exist in this scope.

ตัวอย่างที่ 2:

{
    var userSettingsFile = SettingsFiles.LoadForUser();

    if (someCondition)
    {
        userSettingsFile.Destroy();
    }
}

{
    var appSettingsFile = SettingsFiles.LoadForApp();

    // `userSettingsFile` is out of scope. There is no risk to use it instead of
    // `appSettingsFile`.
}

มันดูผิดหรือเปล่า? คุณจะหลีกเลี่ยงไวยากรณ์ดังกล่าวหรือไม่ เป็นการยากที่จะเข้าใจโดยผู้เริ่มต้น?

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

เมื่อต้องการสำรองข้อมูลนี้ด้วยประสบการณ์ส่วนตัว: เมื่อหลายปีก่อนฉันได้รับมรดกโครงการ C ++ ด้วยรหัสบรรทัด ~ 150K และมีวิธีการสองสามอย่างที่ใช้เทคนิคนี้อย่างแน่นอน และเดาว่าอะไร - วิธีการทั้งหมดนั้นยาวเกินไป ในขณะที่เราปรับโครงสร้างโค้ดส่วนใหญ่ใหม่วิธีการก็เล็กลงและเล็กลงและฉันค่อนข้างมั่นใจว่าไม่มีวิธี "ขอบเขตภายใน" ที่เหลืออยู่อีกต่อไป พวกเขาไม่ต้องการ

มันง่ายกว่ามากสำหรับผู้เริ่มต้น (และโปรแกรมเมอร์) ที่จะคิดถึง:

• ไม่ใช้ตัวแปรที่ไม่เกี่ยวข้อง

กว่าที่จะคิด:

• การเพิ่มโครงสร้างโค้ดโดยมีวัตถุประสงค์เพื่อป้องกันตัวเองจากการไม่ใช้ตัวแปรที่ไม่เกี่ยวข้อง

ยิ่งไปกว่านั้นจากมุมมองของผู้อ่านบล็อกดังกล่าวไม่มีบทบาทที่ชัดเจน: การลบบล็อกดังกล่าวไม่มีผลกระทบต่อการดำเนินการ ผู้อ่านอาจเกาหัวของเขาพยายามคาดเดาสิ่งที่ coder ต้องการบรรลุ

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

ฉันยอมรับว่าการใช้ซ้ำตัวแปรบ่อยกว่าการไม่มีกลิ่นรหัส น่าจะเป็นรหัสดังกล่าวควร refactored ในบล็อกขนาดเล็กในตัวเอง

มีสถานการณ์หนึ่งโดยเฉพาะคือ OTOH ใน C # เมื่อพวกเขามีแนวโน้มที่จะป๊อปอัพ - นั่นคือเมื่อใช้การสร้างกรณีสวิตช์ สถานการณ์ได้รับการอธิบายอย่างดีใน: คำสั่ง C # Switch ที่มี / ไม่มีวงเล็บปีกกา…อะไรคือความแตกต่าง?