Нужно ли писать еще часть в каждом условии if?

Нет, вы, конечно, не должны — по крайней мере, на большинстве языков. (Вы не уточнили; вполне возможно, что есть язык, который делает принудительное выполнение этого.) Вот пример, где я, конечно, не стал бы:

public void DoSomething(string text)
{
    if (text == null)
    {
        throw new ArgumentNullException("text");
    }
    // Do stuff
}

Теперь вы можете поместить основную работу метода в предложение "else" здесь, но это излишне увеличит вложенность. Добавьте еще несколько условий, и все превратится в нечитаемый беспорядок.

По моему опыту, этот шаблон «раннего выхода» довольно распространен и подходит как для возвращаемых значений, так и для исключений. Я знаю, что некоторые предпочитают единственную точку возврата из метода, но в языках, с которыми я работаю (Java, C#), это часто может привести к значительно менее читаемому коду и более глубокой вложенности.

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

public int DoSomething()
{
    // Do some work
    if (conditionBasedOnPreviousWork)
    {
        log.Info("Condition met; returning discount");
        return discount;
    }
    else
    {
        log.Info("Condition not met; returning original price");
        return originalPrice;
    }
}

(Обратите внимание, что я намеренно дал обеим ветвям больше работы, чем просто возврат - в противном случае было бы уместно условное выражение.)

Будет ли это более читаемым без «else»? Это действительно вопрос личного выбора, и я не собираюсь утверждать, что я всегда последователен. Обе ветки с одинаковым отступом каким-то образом придают им равный вес — и, возможно, поощряют возможность рефакторинга позже путем изменения условия... тогда как, если бы мы просто перешли к «возврату исходной цены», рефакторинг помещения этого в блок if и перемещение случая скидки за пределы блока if было бы менее очевидно правильным на первый взгляд.

В императивных языках, таких как Java и C, if - else является оператором и не возвращает значение. Таким образом, вы можете с радостью написать только часть if и продолжить. И я думаю, что это лучшая практика, чем добавлять пустые else после каждых if.

Однако в функциональных языках, таких как Haskell и Clojure, if — это выражение, и оно должно возвращать значение. Таким образом, это должно быть выполнено с помощью else. Однако бывают случаи, когда вам может не понадобиться раздел else. В Clojure для таких случаев есть макрос when, который оборачивает if - else, чтобы вернуть nil в секцию else и избежать его записи.

(when (met? somecondition)
  (dosomething))

Опасность! Опасность, Уилл Робинсон!

http://en.wikipedia.org/wiki/Cargo_cult_programming

Улучшит ли включение пустых блоков else { } качество, удобочитаемость или надежность вашего кода? Думаю, нет.

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

если машина не остановится до того, как я доберусь до стены, я разобьюсь, иначе я не разобьюсь.

Семантика в сторону:

Ответ на этот вопрос зависит от среды и от того, каков будет результат ошибки.

Бизнес-код? Делайте то, что говорят ваши стандарты кодирования.
ИМХО, вы обнаружите, что разъяснение этого, хотя поначалу это кажется слишком трудоемким, станет бесценным через 10 лет, когда вы вернетесь к этому коду. Но это, конечно, не будет концом света, если вы пропустите важное «анти-условие».

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

В этом случае вам нужно сделать две вещи.
Во-первых, вместо проверки на наличие ошибки вы хотите доказать, что нет ошибки. Это требует пессимистического взгляда на вход в любой модуль. Вы предполагаете, что все неправильно, пока не докажете, что это правильно.
Во-вторых: в жизни критично: вы НИКОГДА не хотите навредить пациенту.:

bool everyThingIsSafe = true;
if(darnThereIsAProblem())
{
   reportToUserEndOfWorld();
}
return everyThingIsSafe;

Упс. Я забыл установить для EveryThingIsSafe значение false.
Подпрограмма, вызвавшая этот фрагмент, теперь обманута. Если бы я инициализировал evertThingIsSafe значением false — я всегда в безопасности, но теперь мне нужно предложение else, чтобы указать, что ошибки не было.
И да, я мог бы изменить это на положительный тест, но тогда мне нужно else для обработки ошибки.
И да, я мог бы назначить функцию everyThingIsSafe() для немедленного возврата чека. А затем проверил флаг, чтобы сообщить о проблеме. Неявное else, почему бы не быть явным?
Строго говоря, неявное else, которое это представляет, является разумным.
Для аудитора FDA/безопасности, возможно, нет.
Если оно явное, может указывать на тест, его еще, и что я четко справился с обоими условиями.

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

Найдите Терак-25. 8 тяжело ранены. 3 мертвых.

Я знаю, что опаздываю, но я много думал над этим и хотел поделиться своими результатами.

В критическом коде необходимо учитывать каждую ветвь. Писать else не обязательно, но оставить отметку, что else не нужно и почему. Это поможет рецензенту. Наблюдать:

//negatives should be fixed
if(a < 0) {
    a+=m;
}
//else value is positive

Нет, не требуется писать часть else для оператора if.

На самом деле большинство разработчиков предпочитают и рекомендуют избегать блока else.

то есть

Вместо того, чтобы писать

if (number >= 18) {
    let allow_user = true;
} else {
    let allow_user = false;
}

Большинство разработчиков предпочитают:

let allow_user = false;
if (number >= 18) {
    let allow_user = true;
}

Это чисто вопрос стиля и ясности. Легко представить операторы if, особенно простые, для которых else было бы совершенно излишним. Но когда у вас есть более сложное условное выражение, возможно, обрабатывающее ряд различных случаев, часто бывает полезно явно объявить, что в противном случае ничего не следует делать. В этих случаях я бы оставил комментарий // do nothing в пустом комментарии else, чтобы было ясно, что место намеренно оставлено пустым.

Нет, но лично я предпочитаю всегда включать инкапсулирующие фигурные скобки, чтобы избежать

if (someCondition)
    bar();
    notbar();  //won't be run conditionally, though it looks like it might

foo();

я бы написал

 if (someCondition){
        bar();
        notbar();  //will be run
 }
 foo();

Иногда нет никакой другой части.... и включение пустой просто делает код менее читаемым имхо.

Нет, не надо..

Кроме того, я не думаю, что это хорошая идея для удобочитаемости, поскольку у вас будет много пустых блоков else. что будет не очень приятно видеть.