Сглаживать условно как рефакторинг

Question

Рассмотрим:

if (something) {
    // Code...
}

При установленном CodeRush рекомендуется:

if (!something) {
    return;
}
// Code...

Может кто-нибудь объяснить, как это лучше? Конечно, нет никакой пользы, что когда-либо.

Answer 1

Изолировано, как вы его представили - никакой выгоды. Но mark4o прав: он меньше вложен, что становится очень ясно, если вы посмотрите на четность, скажем, вложенность в 4 уровня:

public void foo() {
    if (a)
        if (b)
            if (c)
                if (d)
                    doSomething();
}

против

public void foo() {
    if (!a)
        return;
    if (!b)
        return;
    if (!c)
        return;
    if (!d)
        return;
    doSomething();
}

раннее возвращение, как это, улучшает читаемость.

Answer 2

В некоторых случаях чистее проверять все ваши входные данные в начале метода и просто выручить, если что-то не так. У вас может быть серия одноуровневых проверок, которые последовательно проверяют все более и более конкретные вещи, пока вы не будете уверены, что ваши данные хороши. Тогда оставшуюся часть метода будет гораздо проще написать, и в ней будет меньше вложенных условных выражений.

Answer 3

На один уровень меньше вложенности.

Answer 4

Это обычный рефакторинг, предназначенный для удобства обслуживания. См:

http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html

С одним условием, это не большое улучшение. Но он следует принципу «быстро провал», и вы действительно начинаете замечать выгоду, когда у вас много условий. Если вы выросли на «структурированном программировании», которое обычно рекомендует, чтобы у функций были отдельные точки выхода, это может показаться неестественным, но если вы когда-нибудь пытались отлаживать код, имеющий три или более уровней вложенных условных выражений, вы начнете ценить это.

Answer 5

Может использоваться, чтобы сделать код более читабельным (за счет меньшего количества вложений). См. здесь для хорошего примера и здесь для хорошего обсуждения достоинств.

Этот тип шаблона обычно используется для замены:

void SomeMethod()
{
    if (condition_1)
    {
        if (condition_2)
        {
            if (condition_3)
            {
                // code
            }
        }
    }
}

С:

void SomeMethod()
{
    if (!condition_1) { return; }
    if (!condition_2) { return; }
    if (!condition_3) { return; }

    // code
}

Что намного проще для глаз.

Answer 6

Я очень хорошо помню, как терял оценки на работе колледжа, потому что ушел с

if (!something) {
    return;
}
// Code...

формат. Мой лектор показал, что было плохой практикой иметь более одной точки выхода в функции. Я думал, что это было чокнутым и спустя 20 с лишним лет компьютерного программирования, я все еще делаю.

Честно говоря, он жил в эпоху, когда lingua franca был C, а функции часто были страницами длинной и полными вложенных условных выражений, затрудняющих отслеживание происходящего.

Тогда и сейчас, тем не менее, простота является королем: сохранение небольших функций и их правильное комментирование - лучший способ сделать вещи читабельными и понятными.

Answer 7

Хорошо, посмотрите на это так (я буду использовать php в качестве примера):

Вы заполняете форму и переходите на эту страницу: validate.php

пример 1:

<?php

if (valid_data($_POST['username'])) {

    if (valid_data($_POST['password'])) {

        login();

    } else {
        die();
    }

} else {
    die();
}

?>

против

<?php

if (!valid_data($_POST['username'])) {
    die();
}

if (!valid_data($_POST['password'])) {
    die();  
}

login();

?>

Какой из них лучше и проще поддерживать? Помните, что это просто проверка двух вещей. Вообразите это для страницы регистрации или чего-то еще.

Answer 8

IMO, это зависит от того, является ли something или !something исключительным случаем. Если в коде something имеется значительное количество кода, тогда использование условного выражения !something имеет больше смысла для удобочитаемости и потенциального сокращения вложенности.

Answer 9

Я не думаю, что CodeRush рекомендует его, а просто предлагает его в качестве опции.