Đảo ngược một câu lệnh IF

Vì vậy, tôi đã lập trình được vài năm nay và gần đây đã bắt đầu sử dụng ReSharper nhiều hơn. Một điều mà ReSharper luôn gợi ý cho tôi là "đảo ngược câu lệnh 'nếu' để giảm lồng nhau".

Hãy nói rằng tôi có mã này:

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
    }
}

Và ReSharper sẽ đề nghị tôi làm điều này:

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

Có vẻ như ReSharper sẽ LUÔN đề nghị tôi đảo ngược IF, bất kể việc lồng nhau đang diễn ra như thế nào. Vấn đề này là tôi giống như làm tổ trong ít nhất MỘT SỐ tình huống. Đối với tôi có vẻ dễ đọc hơn và tìm hiểu những gì đang diễn ra ở một số nơi. Điều này không phải lúc nào cũng đúng, nhưng đôi khi tôi cảm thấy thoải mái hơn khi làm tổ.

Câu hỏi của tôi là: ngoài sở thích cá nhân hoặc khả năng đọc, có lý do để giảm lồng không? Có một sự khác biệt hiệu suất hoặc một cái gì đó khác mà tôi có thể không nhận thức được?

Nó phụ thuộc. Trong ví dụ của bạn có ifcâu lệnh không đảo ngược không phải là vấn đề, bởi vì phần thân của ifnó rất ngắn. Tuy nhiên, bạn thường muốn đảo ngược các tuyên bố khi cơ thể phát triển.

Chúng ta chỉ là con người và giữ nhiều thứ cùng một lúc trong đầu thật khó khăn.

Khi phần thân của câu lệnh lớn, việc đảo ngược câu lệnh không chỉ làm giảm lồng mà còn cho nhà phát triển biết họ có thể quên mọi thứ bên trên câu lệnh đó và chỉ tập trung vào phần còn lại. Bạn rất có thể sử dụng các câu lệnh đảo ngược để loại bỏ các giá trị sai càng sớm càng tốt. Một khi bạn biết những thứ đó nằm ngoài trò chơi, điều duy nhất còn lại là các giá trị thực sự có thể được xử lý.

Đừng tránh tiêu cực. Con người mút như phân tích chúng ngay cả khi CPU yêu thích chúng.

Tuy nhiên, hãy tôn trọng thành ngữ. Con người chúng ta là sinh vật của thói quen vì vậy chúng tôi thích những con đường mòn hơn là những con đường trực tiếp đầy cỏ dại.

foo != nullthật đáng buồn, đã trở thành một thành ngữ. Tôi hầu như không nhận thấy các phần riêng biệt nữa. Tôi nhìn vào đó và chỉ nghĩ, "ồ, an toàn để chấm dứt foongay bây giờ".

Nếu bạn muốn lật ngược điều đó (ồ, một ngày nào đó, làm ơn) bạn cần một trường hợp thực sự mạnh mẽ. Bạn cần một cái gì đó sẽ khiến mắt tôi dễ dàng trượt khỏi nó và hiểu nó ngay lập tức.

Tuy nhiên, những gì bạn đã cho chúng tôi là:

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

Mà thậm chí không giống nhau về mặt cấu trúc!

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    if(someGlobalObject == null) continue;
    someSideEffectObject = someGlobalObject.SomeProperty;
}

Đó không phải là điều mà bộ não lười biếng của tôi mong đợi nó sẽ làm. Tôi nghĩ rằng tôi có thể tiếp tục thêm mã độc lập nhưng tôi không thể. Điều này khiến tôi nghĩ về những điều tôi không muốn nghĩ về bây giờ. Bạn đã phá vỡ thành ngữ của tôi nhưng không cho tôi một cái tốt hơn. Tất cả chỉ vì bạn muốn bảo vệ tôi khỏi một điều tiêu cực đã thiêu rụi cái tôi nhỏ bé khó chịu vào tâm hồn tôi.

Rất tiếc, có thể ReSharper đã đúng khi đề xuất 90% thời gian này nhưng trong kiểm tra null tôi nghĩ bạn đã tìm thấy một trường hợp góc mà nó bị bỏ qua tốt nhất. Các công cụ đơn giản là không tốt trong việc dạy cho bạn biết mã nào có thể đọc được. Hỏi một con người. Làm một đánh giá ngang hàng. Nhưng đừng mù quáng làm theo công cụ.

Đó là lập luận cũ về việc phá vỡ có tệ hơn khi làm tổ không.

Mọi người dường như chấp nhận trả về sớm để kiểm tra tham số, nhưng nó cau mày với phần lớn phương thức.

Cá nhân tôi tránh tiếp tục, phá vỡ, goto vv ngay cả khi nó có nghĩa là làm tổ nhiều hơn. Nhưng trong hầu hết các trường hợp, bạn có thể tránh cả hai.

foreach (someObject in someObjectList.where(i=>i != null))
{
    someOtherObject = someObject.SomeProperty;
}

Rõ ràng việc làm tổ không làm cho mọi thứ khó theo dõi khi bạn có nhiều lớp

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
            }
        }
    }
}

Điều tồi tệ nhất là khi bạn có cả hai

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
                return;
            }
            continue;
        }
        someObject.z --;
        if(myFunctionWithSideEffects(someObject) > 6) break;
    }
}

Vấn đề với continuelà nếu bạn thêm nhiều dòng vào mã, logic sẽ trở nên phức tạp và có khả năng chứa lỗi. ví dụ

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    ...  imagine that there is some code here ...

    // added later by a Junior Developer
    doSomeOtherFunction(someObject);
}

Bạn có muốn gọi doSomeOtherFunction()cho tất cả someObject, hoặc chỉ khi không null? Với mã gốc, bạn có tùy chọn và nó rõ ràng hơn. Với continuemột người có thể quên "oh, vâng, ở đó chúng tôi đã bỏ qua null" và bạn thậm chí không có tùy chọn để gọi nó cho tất cả một số Dự án, trừ khi bạn thực hiện cuộc gọi đó khi bắt đầu phương thức có thể không thực hiện được hoặc không chính xác vì những lý do khác

Vâng, rất nhiều lồng là xấu xí và có thể gây nhầm lẫn, nhưng trong trường hợp này tôi sử dụng phong cách truyền thống.

Câu hỏi thưởng: Tại sao có null trong danh sách đó để bắt đầu? Có thể tốt hơn là không bao giờ thêm null ở vị trí đầu tiên, trong trường hợp đó, logic xử lý đơn giản hơn nhiều.

Ý tưởng là sự trở lại sớm. Sớm returntrong một vòng lặp trở thành sớm continue.

Rất nhiều câu trả lời hay cho câu hỏi này: Tôi nên trở về từ một chức năng sớm hay sử dụng câu lệnh if?

Lưu ý rằng trong khi câu hỏi được đóng lại dựa trên ý kiến, 430+ phiếu ủng hộ trả lại sớm, ~ 50 phiếu là "nó phụ thuộc" và 8 là chống lại trả lại sớm. Vì vậy, có một sự đồng thuận đặc biệt mạnh mẽ (hoặc điều đó, hoặc tôi rất tệ trong việc đếm, điều đó là hợp lý).

Cá nhân, nếu thân vòng lặp có thể tiếp tục sớm và đủ lâu để nó có vấn đề (3-4 dòng), tôi có xu hướng trích xuất thân vòng lặp thành một chức năng nơi tôi sử dụng trả về sớm thay vì tiếp tục sớm.

Kỹ thuật này rất hữu ích để xác nhận các điều kiện trước khi phần lớn phương thức của bạn xảy ra khi các điều kiện đó được đáp ứng.

Chúng tôi thường xuyên đảo ngược ifscông việc của tôi và sử dụng một bóng ma khác. Nó thường được sử dụng khá thường xuyên khi xem xét PR tôi có thể chỉ ra làm thế nào đồng nghiệp của tôi có thể loại bỏ ba cấp độ lồng nhau! Nó xảy ra ít thường xuyên hơn kể từ khi chúng tôi tung ra ifs của mình.

Dưới đây là một ví dụ đồ chơi của một cái gì đó có thể được tung ra

function foobar(x, y, z) {
    if (x > 0) {
        if (z != null && isGamma(y)) {
            // ~10 lines of code
            // return something
        }
        else {
           return y
        }
    }
    else {
      return y + z
    }
}

Mã như thế này, trong đó có MỘT trường hợp thú vị (trong đó phần còn lại chỉ đơn giản là trả về hoặc khối lệnh nhỏ) là phổ biến. Nó là tầm thường để viết lại như trên

function foobar(x, y, z) {
    if (x <=0) {
        return y + z
    }
    if (z == null || !isGamma(y) {
       return y
    }
    // ~ 10 lines of code
    // return something
}

Ở đây, mã quan trọng của chúng tôi, 10 dòng không bao gồm, không được thụt ba trong hàm. Nếu bạn có kiểu đầu tiên, hoặc bạn muốn cấu trúc lại khối dài thành một phương thức hoặc chịu đựng sự thụt lề. Đây là nơi tiết kiệm. Ở một nơi, đây là một khoản tiết kiệm không đáng kể nhưng qua nhiều phương thức trong nhiều lớp, bạn tiết kiệm được nhu cầu tạo một hàm bổ sung để làm cho mã sạch hơn và bạn không có nhiều mức độ ghê gớm thụt đầu dòng .

Đáp lại mẫu mã của OP, tôi đồng ý rằng đó là sự sụp đổ quá mức. Đặc biệt là trong 1TB, kiểu tôi sử dụng, đảo ngược làm cho mã tăng kích thước.

Đề xuất chia sẻ lại thường hữu ích nhưng phải luôn được đánh giá nghiêm túc. Nó tìm kiếm một số mẫu mã được xác định trước và đề xuất các phép biến đổi, nhưng nó không thể tính đến tất cả các yếu tố làm cho mã ít nhiều có thể đọc được cho con người.

Tất cả những thứ khác đều bằng nhau, ít làm tổ hơn là tốt hơn, đó là lý do tại sao ReSharper sẽ đề xuất một phép biến đổi làm giảm việc lồng. Nhưng tất cả những thứ khác không bằng nhau: Trong trường hợp này, phép biến đổi yêu cầu giới thiệu a continue, có nghĩa là mã kết quả thực sự khó theo dõi hơn.

Trong một số trường hợp, việc trao đổi một mức lồng nhau để thực sự continue có thể là một sự cải tiến, nhưng điều này phụ thuộc vào ngữ nghĩa của mã được đề cập, vượt quá sự hiểu biết về các quy tắc cơ học của ReSharpers.

Trong trường hợp của bạn, đề xuất ReSharper sẽ làm cho mã tồi tệ hơn. Vì vậy, chỉ cần bỏ qua nó. Hoặc tốt hơn: Đừng sử dụng chuyển đổi được đề xuất, nhưng hãy suy nghĩ một chút về cách cải thiện mã. Lưu ý rằng bạn có thể gán cùng một biến nhiều lần, nhưng chỉ có phép gán cuối cùng có hiệu lực, vì trước đó sẽ bị ghi đè. Điều này trông giống như một lỗi. Đề xuất ReSharpers không sửa lỗi, nhưng nó làm cho rõ ràng hơn một chút rằng logic đáng ngờ đang diễn ra.

Tôi nghĩ rằng điểm lớn hơn ở đây là mục đích của vòng lặp quyết định cách tốt nhất để tổ chức dòng chảy trong vòng lặp. Nếu bạn đang lọc ra một số yếu tố trước khi bạn lặp lại các yếu tố còn lại, thì việc continuera sớm có ý nghĩa. Tuy nhiên, nếu bạn đang thực hiện các loại xử lý khác nhau trong một vòng lặp, có thể có ý nghĩa hơn để làm cho điều đó ifthực sự rõ ràng, chẳng hạn như:

for(obj in objectList) {
    if(obj == null) continue;
    if(obj.getColour().equals(Color.BLUE)) {
        // Handle blue objects
    } else {
        // Handle non-blue objects
    }
}

Lưu ý rằng trong Luồng Java hoặc các thành ngữ chức năng khác, bạn có thể tách bộ lọc khỏi vòng lặp, bằng cách sử dụng:

items.stream()
    .filter(i -> (i != null))
    .filter(i -> i.getColour().equals(Color.BLUE))
    .forEach(i -> {
        // Process blue objects
    });

Ngẫu nhiên, đây là một trong những điều tôi thích về Perl bị đảo ngược nếu ( unless) được áp dụng cho các câu lệnh đơn, cho phép loại mã sau đây, mà tôi thấy rất dễ đọc:

foreach my $item (@items) {
    next unless defined $item;
    carp "Only blue items are supported! Failed on item $item" 
       unless ($item->get_colour() eq 'blue');
    ...
}