Стиль кодирования ... ошибка первая или последняя?

Question

Что лучше в целом с точки зрения заказа? Вы ставите условие неисправности сверху или снизу?

if (noProblems == true) {
    // do stuff
} else {
    // deal with problem
}

OR

if (noProblems == false) {
    // deal with problem
} else {
    // do stuff
}

Answer 1

Я хотел бы сначала устранить случаи ошибок - и вернуться из функции раньше, чтобы «счастливый путь» оставался не вложенным, например,

if (some error condition)
{
    //handle it
    return;
}
//implicit else for happy path
...

если легко определить условия, ведущие к счастливому пути, то во что бы то ни стало поставьте этот пункт первым (спасибо Марцин!)

Answer 2

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

Из раздела «Код завершен, 2-е издание», раздел 15.1:

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

Answer 3

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

Answer 4

Почему бы не создать одну точку выхода из функции и выполнить там надлежащую очистку вместо нескольких возвратов ...

DWORD bRetVal= TRUE;
if(foo is null) 
{
   bRetVal = FALSE;
   goto Error;
}
else
{
// do something
}

Exit:
 return bRetVal;

Answer 5

Как и в случае try / catch Я выполняю нормальный поток и затем обрабатываю условия исключения.

Это не означает, что проверка / очистка ошибок не происходит в первую очередь, но это если я не доверяю тому, что мне передали.

например.,

if (foo is null) then
    // bail
end if

if (bar == foo) then
    // foo hasn't been changed... print the regular report
else
    // foo has changed, run the reconciliation report instead.
end if

Мне нравится, когда счастливая история течет как прямая линия, а несчастная история разворачивается на своей собственной волне.

Answer 6

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

Кроме этого, вы создали вещи, так что вы не можете

// do stuff

после вас

// deal with problem

так что за этим одно кажется таким же хорошим, как и другое.

Answer 7

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

Answer 8

Зависит от того, что вам понятнее. Я имею в виду, что имеет больше смысла, что noProblems имеет истинное значение или что оно имеет ложное значение.

Например, для isDeviceEnabled () я бы всегда проверял истинный результат, так как «Enabled» неявно имеет положительное значение. Для неявного отрицательного значения мы можем проверить, например, на «isMemoryAvailable ()», возможно, потому что вам нужно проверять, только если больше нет места для новых объектов / массивов или других данных.