Các câu lệnh if / other nên được sắp xếp bởi sự hiếm hoi của các trường hợp hoặc khó xử lý chúng?

Trong một số mã tôi đang viết ngay bây giờ, tôi có một cái gì đó như thế này:

if (uncommon_condition) {
    do_something_simple();
} else {
    do();
    something();
    long();
    and();
    complicated();
}

Một phần trong tôi nghĩ rằng "Nó ổn theo cách viết của nó. Những trường hợp đơn giản nên đi trước và những trường hợp phức tạp hơn nên đi tiếp." Nhưng một phần khác nói: "Không! elseMã phải tuân theo if, vì iflà để xử lý các trường hợp bất thường và elselà để xử lý tất cả các trường hợp khác." Cái nào đúng hay thích?

Đặt hàng theo khả năng của họ được thực hiện. Các điều kiện phổ biến nhất, rất có thể, v.v. nên đi trước.

"Khó xử lý chúng" nên được xử lý bằng cấu trúc mã, trừu tượng hóa, v.v. trong ví dụ, khối khác có thể được cấu trúc lại thành lệnh gọi phương thức đơn. Bạn muốn các ifmệnh đề của bạn ở cùng một mức độ trừu tượng.

if ( ! LotteryWinner ) {
    GoToWorkMonday();
} else {
    PlanYearLongVacation();
}

Cố gắng tăng cường khả năng đọc. Một cách là đặt khối mã dài hơn vào phần khác.

if (s == null)
     // short code
else 
     // long 
     // code
     // block

dễ đọc hơn

if (s != null)
    // long
    // code
    // block
else
    // short code

Không có quy tắc cố định như vậy tôi đã nghe về việc sử dụng nhưng tôi làm theo như thế này

if(usual)
{
(more often)
}
else (unusual)
{
(rarely occurring)
}

Nhưng nếu cả hai đều có cùng chức năng với các thuộc tính khác nhau thì tốt nhất nên sử dụng bất thường trước để thông thường để bạn có thể lưu một hướng dẫn.

if(x == 0)  // 1
  {x = 1;}  // 2
else
  {x = 2;}  // 3

Đối với mã lắp ráp mã ở trên sẽ là một cái gì đó như thế này:

1. 000d 837DFC00        cmpl    $0, -4(%ebp)
   0011 7509            jne .L2

2. 0013 C745FC01        movl    $1, -4(%ebp)
   001a EB07            jmp .L3

    .L2:
3.001c C745FC02         movl    $2, -4(%ebp)

        .L3:

Nếu điều kiện bên trong if là true thì luồng là 1-> 2 (4 lần nhập)
Điều kiện bên trong if là false thì luồng là 1-> 3 (3 lần nhập)

Vì vậy, tốt hơn là đặt các sự kiện bất thường hoặc hiếm khi xảy ra nếu một phần và tình trạng bình thường khác để chúng ta có thể lưu một hướng dẫn mỗi lần ;-)

Tôi đã thấy rằng mẫu ngược lại chính xác dẫn đến việc đọc mã dễ dàng hơn và giảm hoặc loại bỏ các câu lệnh if lồng nhau. Tôi gọi nó là một mẫu "găng tay". (. Trong câu chuyện kể, một gauntlet sẽ là một loạt các thách thức mà phải được đáp ứng thành công trước khi nhiệm vụ cuối cùng được hoàn thành) Bằng cách xử lý vụ việc cạnh bạn đầu tiên , bạn cho phép phần chính của mã của bạn được sạch sẽ và súc tích:

if(gauntlet_1){ handle the first gauntlet condition }; 
if(gauntlet_2){ handle the second gauntlet condition };
...
// All preconditions (gauntlets) have been successfully handled

// Perform your main task here

Đối với tôi, đó là về các điều kiện hơn là sự phức tạp của mã họ thực thi. Bạn cần phải đặt hàng các điều kiện để bẫy các điều kiện bất thường trước, sau đó phổ biến hơn sau. Ngoài ra, nếu mã khác thực sự dài và phức tạp, có lẽ tôi sẽ tạo một phụ cho điều đó, để giữ cho phần điều kiện rõ ràng cho người đọc.

Tôi không có một quy tắc cố định, nhưng nói chung tôi tuân theo quy tắc này - trước tiên, hãy xem xét nơi có một mẫu thiết kế bị bỏ lỡ sẽ đưa ra yếu tố này. Nếu không, tôi viết nó để điều kiện trong if được hiểu rõ nhất. Đó là, tránh tiêu cực kép và tương tự.

Đối với các kịch bản như vậy không có quy tắc ngón tay cái cho nó. Nhưng có lẽ chúng ta có thể làm theo để viết mã dương hoặc rất có thể trong khối if và bỏ qua trong khối khác hoặc các trường hợp mặc định.