Ненужное выражение 'else'

Ответ 1

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

doLotOfStuff();
if (condition) { 
    return foo; 
} 
return bar; 

Но если любая возможность разумна и это просто выбор между ними, я бы позволил структуре кода показать эту симметрию.

doLotOfStuff();
if (condition) { 
    return foo; 
} else {
    return bar; 
}

Код для программиста читается, а не компилятор.

Ответ 2

Когда-то считалось (и, вероятно, по-прежнему некоторым), что функции должны иметь одну точку входа (легкую, но актуальную, когда вы рассматриваете язык ассемблера) и одну точку выхода.

Одна точка выхода хороша с точки отладки (так как вы можете поместить один вахту/перерыв на одной линии и знать, что вы ее пройдете), но может привести к некоторому ужасающему вложению, поэтому чаще, чем не читаемость, как правило, выигрывает вне. Что порождает наименьшее количество гнездования, наименьшие строки кода и наиболее читаемый конечный результат? В конечном счете это, как правило, гораздо важнее всего.

То, что стоит последнего, может быть лучше выражено как:

return condition ? foo : bar;

Предполагая, что condition не слишком длинный.

Не слишком беспокоитесь о предполагаемом "чистоте" кода. Это нерелевантное отвлечение. Сделайте все читаемым и, как правило, последовательным.

Ответ 3

Хорошо, некоторые известные эксперты Java утверждают, что всегда нужно бороться, чтобы свести к минимуму объем вещей, а также мое мнение.

Мои преподаватели в университете всегда мучили меня, что я должен писать такие вещи, как это было опубликовано кем-то раньше:

String result = null;
doLotOfStuff();
if (condition) {
    result = foo;
} else {
    result = bar;
}
return result;

Результат переменной теперь имеет довольно большой объем. В дополнение к большому количеству вложенности это, как правило, очень нечитаемо, если вы немного больше здесь, скажем, у вас есть еще один цикл for-loop.

Я думаю, что это намного лучше:

doLotOfStuff();
return condition ? foo : bar;

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

Мне очень нравится

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

Предупреждение "Ненужное другое выражение" помогает в этом.

Ответ 4

Ну, я думаю, что использование множественного возврата не читается.

Я предпочитаю код как:

String result = null;

doLotOfStuff();
if (condition) { 
    result = foo; 
} else {
    result = bar; 
}

return result;

Несколько возвратов сложно понять. Но в вашем случае я предпочту postCheck

doLotOfStuff();
if (condition) { 
    return foo; 
} else {
    return bar; 
}

Ответ 5

Я нахожу эту форму

doLotOfStuff();
if (condition) { 
    return foo; 
}
return bar; 

чтобы быть более читаемым, чем тот, у которого есть else, он меньше кода и более интуитивно понятен, если вы думаете об этом как остерегающий, как в Рефакторинге Фаулера.

Вопрос о множественных точках возврата.

Ответ 6

Я знаю, что без проверки IDE для меня я почти всегда использую ненужное выражение else. Часто я нахожу, что сначала он лучше читает с ним, но обычно удаляет его, когда он указывается, поскольку я вижу, что он не нужен, и затем он меня обманывает...

Ответ 7

Назовите меня плохим мальчиком, но я бы обычно пошел с:

doLotOfStuff();
return condition ? foo : bar;

Операция с одним возвратом, очень читаемая.

Ответ 8

По моему мнению, проверка затмения не очень полезна. То, что вы должны делать, зависит от вашего контекста программы. Предложения Else предназначены для альтернатив (или того или другого), тогда как переход к возврату (условие else) более уместен, если у вас есть несколько условий, которые могут быть истинными, а провал - это скорее реакция по умолчанию, которую вы не используете действительно вызывают слишком часто. Таким образом, вы используете как код, передающий значение, так и проверку на наличие или отсутствие, не полезны.

Ответ 9

Некоторые программисты утверждают, что return в середине функции - плохая практика. Возможно, для простой проверки ввода функции, как в вашем первом примере, это нормально и приемлемо, но в других случаях я предпочел бы установить переменную result, как в ответе Джерома.

Ответ 10

Если я прослежу следующий код, я заметим, что первый if-блок является исключительным блоком кода. Однако, если я добавлю "else" к этому, я могу рассматривать оба блока операционного кода.

Кроме того, для основного операционного блока могут быть некоторые вложенные блоки. Я предпочитаю минимизировать вложенный уровень.

public String myMethod(input) {
    if (!validate(input)) {
        return "invalid input";
    }

    operation1();
    if (someCondition) {
        operation2();
    } else {
        operation3();
    }
    operation4();
    operation5();
    return operation6();
}