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

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

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 было бы менее очевидно правильным на первый взгляд.

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

Нет, не нужно...

Кроме того, я не думаю, что это хорошая идея для читабельности, поскольку у вас будет много пустых блоков 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();

В императивных языках, таких как Java и C, if - else является оператором и не возвращает ценность. Так что вы можете с радостью написать только часть if и продолжить. И я думаю, что это лучше, чем добавлять пустые else s после каждого 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 {} как-то улучшить качество, читаемость или надежность вашего кода? Думаю, нет.

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