Là việc sử dụng các khối phạm vi nội bộ trong một phong cách xấu?

Có một số trường hợp (khá hiếm) có nguy cơ:

• sử dụng lại một biến không có ý định sử dụng lại (xem ví dụ 1),

• hoặc sử dụng một biến thay vì một biến khác, gần đúng về mặt ngữ nghĩa (xem ví dụ 2).

Ví dụ 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`.
}

Ví dụ 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.

Rủi ro này có thể được giảm thiểu bằng cách giới thiệu một phạm vi:

Ví dụ 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.

Ví dụ 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`.
}

Trông nó có sai không? Bạn sẽ tránh cú pháp như vậy? Có khó hiểu bởi người mới bắt đầu?

Nếu chức năng của bạn quá dài đến nỗi bạn không thể nhận ra bất kỳ tác dụng phụ không mong muốn nào hoặc tái sử dụng bất hợp pháp các biến nữa, thì đã đến lúc chia nó thành các hàm nhỏ hơn - điều này làm cho phạm vi bên trong trở nên vô nghĩa.

Để hỗ trợ điều này bằng một số kinh nghiệm cá nhân: vài năm trước tôi đã kế thừa một dự án kế thừa C ++ với ~ 150K dòng mã và nó chứa một vài phương thức sử dụng chính xác kỹ thuật này. Và đoán xem - tất cả những phương pháp đó quá dài. Khi chúng tôi tái cấu trúc hầu hết mã đó, các phương thức trở nên nhỏ hơn và nhỏ hơn và tôi khá chắc chắn rằng không còn phương thức "phạm vi nội bộ" nào nữa; họ chỉ đơn giản là không cần thiết.

Người mới bắt đầu (và bất kỳ lập trình viên) nào cũng dễ dàng nghĩ đến:

• không sử dụng biến không liên quan

hơn là nghĩ về:

• thêm các cấu trúc mã nhằm ngăn chặn bản thân không sử dụng một biến không liên quan.

Hơn nữa, từ quan điểm của người đọc, các khối như vậy không có vai trò rõ ràng: loại bỏ chúng không có tác động đến việc thực hiện. Người đọc có thể gãi đầu cố gắng đoán những gì lập trình viên muốn đạt được.

Sử dụng một phạm vi là đúng kỹ thuật. Nhưng nếu bạn muốn làm cho mã của mình dễ đọc hơn thì bạn nên trích xuất phần đó trong một phương thức khác và đặt tên đầy đủ đó. Theo cách này, bạn có thể đưa ra một phạm vi các biến của mình và cũng đưa ra một tên của nhiệm vụ của bạn.

Tôi đồng ý rằng việc tái sử dụng biến thường xuyên hơn không phải là mùi mã. Có lẽ mã như vậy nên được cấu trúc lại trong các khối nhỏ hơn, khép kín.

Có một kịch bản cụ thể, OTOH, trong C #, khi chúng có xu hướng bật lên - đó là khi sử dụng các cấu trúc trường hợp chuyển đổi. Tình huống được giải thích rất độc đáo trong: C # Chuyển câu lệnh có / không có dấu ngoặc nhọn Cách khác biệt?