Sử dụng phương thức return bên trong một phương thức void có phải là một phương pháp không tốt?

Hãy tưởng tượng đoạn mã sau:

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

Sử dụng trả về bên trong phương thức void có được không? Nó có bất kỳ hình phạt hiệu suất? Hoặc sẽ tốt hơn nếu viết một mã như thế này:

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

Trả về trong một phương thức void không phải là xấu, là một thực tế phổ biến để đảo ngược các ifcâu lệnh để giảm việc lồng vào nhau .

Và việc ít lồng ghép hơn vào các phương pháp của bạn sẽ cải thiện khả năng đọc và khả năng bảo trì mã.

Trên thực tế, nếu bạn có một phương thức void mà không có bất kỳ câu lệnh trả về nào, trình biên dịch sẽ luôn tạo ra một lệnh ret ở cuối nó.

Có một lý do tuyệt vời khác để sử dụng bảo vệ (trái ngược với mã lồng nhau): Nếu một lập trình viên khác thêm mã vào hàm của bạn, họ đang làm việc trong một môi trường an toàn hơn.

Xem xét:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

đấu với:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

Bây giờ, hãy tưởng tượng một lập trình viên khác thêm dòng: obj.DoSomethingElse ();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

Rõ ràng đây là một trường hợp đơn giản, nhưng lập trình viên đã thêm một lỗi vào chương trình trong trường hợp đầu tiên (mã lồng nhau). Trong ví dụ thứ hai (thoát ra sớm với lính canh), khi bạn vượt qua được lính canh, mã của bạn sẽ an toàn khỏi việc vô tình sử dụng tham chiếu rỗng.

Chắc chắn, một lập trình viên giỏi không mắc những lỗi như thế này (thường xuyên). Nhưng phòng bệnh hơn chữa bệnh - chúng ta có thể viết mã theo cách loại bỏ hoàn toàn nguồn lỗi tiềm ẩn này. Việc lồng ghép thêm phức tạp, vì vậy, các phương pháp hay nhất khuyên bạn nên cấu trúc lại mã để giảm việc lồng ghép.

Tập dượt ??? Không đời nào. Trên thực tế, luôn tốt hơn nếu xử lý xác thực bằng cách quay lại từ phương thức sớm nhất nếu quá trình xác thực không thành công. Nếu không, nó sẽ dẫn đến một lượng lớn ifs & elses lồng nhau. Kết thúc sớm cải thiện khả năng đọc mã.

Ngoài ra, hãy kiểm tra các câu trả lời cho một câu hỏi tương tự: Tôi có nên sử dụng câu lệnh return / continue thay vì if-else không?

Nó không phải là thực hành xấu (vì tất cả các lý do đã được nêu). Tuy nhiên, bạn càng có nhiều lợi nhuận trong một phương thức, thì càng có nhiều khả năng nó được chia thành các phương thức logic nhỏ hơn.

Ví dụ đầu tiên là sử dụng câu lệnh bảo vệ. Từ Wikipedia :

Trong lập trình máy tính, bảo vệ là một biểu thức boolean phải đánh giá là true nếu việc thực thi chương trình tiếp tục trong nhánh được đề cập.

Tôi nghĩ rằng có một nhóm bảo vệ đứng đầu một phương pháp là một cách hoàn toàn dễ hiểu để lập trình. Về cơ bản nó nói "không thực hiện phương thức này nếu bất kỳ phương pháp nào trong số này là đúng".

Vì vậy, nói chung nó sẽ như thế này:

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

Tôi nghĩ điều đó dễ đọc hơn sau đó:

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

Không có hình phạt về hiệu suất, tuy nhiên đoạn mã thứ hai dễ đọc hơn và do đó dễ bảo trì hơn.

Trong trường hợp này, ví dụ thứ hai của bạn là mã tốt hơn, nhưng điều đó không liên quan gì đến việc trả về từ một hàm void, nó chỉ đơn giản là vì mã thứ hai trực tiếp hơn. Nhưng trả về từ một hàm void là hoàn toàn tốt.

Hoàn toàn ổn và không có 'hình phạt hiệu suất', nhưng đừng bao giờ viết câu lệnh 'nếu' không có dấu ngoặc.

Luôn luôn

if( foo ){
    return;
}

Nó dễ đọc hơn; và bạn sẽ không bao giờ vô tình cho rằng một số phần của mã nằm trong câu lệnh đó khi chúng không nằm trong câu lệnh đó.

Tôi sẽ không đồng ý với tất cả các bạn những người trẻ tuổi đánh cá về điều này.

Sử dụng return ở giữa một phương thức, void hoặc cách khác, là một thực tiễn rất tồi, vì những lý do đã được trình bày khá rõ ràng, gần bốn mươi năm trước, bởi quá cố Edsger W. Dijkstra, bắt đầu trong "Tuyên bố GOTO được coi là có hại ", và tiếp tục trong" Lập trình có cấu trúc ", của Dahl, Dijkstra và Hoare.

Quy tắc cơ bản là mọi cấu trúc điều khiển và mọi mô-đun phải có chính xác một lối vào và một lối ra. Một kết quả trả về rõ ràng ở giữa mô-đun phá vỡ quy tắc đó và khiến việc suy luận về trạng thái của chương trình trở nên khó khăn hơn nhiều, do đó, điều này làm cho việc nói chương trình có đúng hay không sẽ khó hơn nhiều (đó là một thuộc tính mạnh hơn nhiều so với "liệu nó có hoạt động hay không").

"Tuyên bố GOTO bị coi là có hại" và "Lập trình có cấu trúc" đã khởi động cuộc cách mạng "Lập trình có cấu trúc" trong những năm 1970. Hai phần đó là lý do chúng ta có các cấu trúc điều khiển if-then-else, while-do và các cấu trúc điều khiển rõ ràng khác ngày nay và tại sao các câu lệnh GOTO bằng ngôn ngữ cấp cao lại nằm trong danh sách Các loài nguy cấp. (Ý kiến ​​cá nhân của tôi là chúng cần phải nằm trong danh sách Các loài tuyệt chủng.)

Điều đáng chú ý là Message Flow Modulator, phần mềm quân sự đầu tiên mà EVER đã vượt qua thử nghiệm chấp nhận trong lần thử đầu tiên, không có sai lệch, từ bỏ, hoặc nguyên văn "vâng, nhưng", được viết bằng một ngôn ngữ thậm chí không có một tuyên bố GOTO.

Cũng cần nhắc lại rằng Nicklaus Wirth đã thay đổi ngữ nghĩa của câu lệnh RETURN trong Oberon-07, phiên bản mới nhất của ngôn ngữ lập trình Oberon, khiến nó trở thành một đoạn sau của phần khai báo của một thủ tục đã nhập (tức là hàm), thay vì một câu lệnh thực thi trong phần thân của hàm. Sự giải thích của anh ấy về sự thay đổi nói rằng anh ấy đã làm điều đó chính xác vì biểu mẫu trước đó LÀ vi phạm nguyên tắc một lối ra của Lập trình có cấu trúc.

Trong khi sử dụng bảo vệ, hãy đảm bảo bạn tuân theo một số nguyên tắc nhất định để không làm người đọc nhầm lẫn.

• chức năng làm một việc
• bảo vệ chỉ được giới thiệu như là logic đầu tiên trong hàm
• phần unnested chứa ý định cốt lõi của hàm

Thí dụ

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

Ném ngoại lệ thay vì trả về không có gì khi đối tượng là null, v.v.

Phương thức của bạn mong đợi đối tượng không phải là null và không phải như vậy, vì vậy bạn nên ném ngoại lệ và để người gọi xử lý điều đó.

Nhưng việc trở về sớm không phải là xấu.