Следует ли использовать «другое» в ситуациях, когда поток управления делает его избыточным?

Иногда я сталкиваюсь с кодом, подобным следующему примеру (что именно делает эта функция, выходит за рамки этого вопроса):

function doSomething(value) {
  if (check1(value)) {
    return -1;
  }
  else if (check2(value)) {
    return value;
  }
  else {
    return false;
  }
}

Как вы можете видеть, if, else ifи elseутверждения используются в сочетании с returnзаявлением. Это кажется довольно интуитивным для случайного наблюдателя, но я думаю, что было бы более элегантно (с точки зрения разработчика программного обеспечения) отбросить else-s и упростить код следующим образом:

function doSomething(value) {
  if (check1(value)) {
    return -1;
  }
  if (check2(value)) {
    return value;
  }
  return false;
}

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

Что из перечисленного больше соответствует хорошей практике кодирования? Есть ли недостатки любого метода в отношении читабельности кода?

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

Мне нравится тот, без elseи вот почему:

function doSomething(value) {
  //if (check1(value)) {
  //  return -1;
  //}
  if (check2(value)) {
    return value;
  }
  return false;
}

Потому что это не сломало ничего, что не должно было быть.

Ненавижу взаимозависимость во всех ее формах (включая именование функций check2()). Изолировать все, что можно изолировать. Иногда вам нужно, elseно я не вижу этого здесь.

Я думаю, что это зависит от семантики кода. Если ваши три случая зависят друг от друга, укажите это явно. Это повышает удобочитаемость кода и облегчает понимание для всех остальных. Пример:

if (x < 0) {
    return false;
} else if (x > 0) {
    return true;
} else {
    throw new IllegalArgumentException();
}

Здесь вы явно зависите от стоимости xво всех трех случаях. Если вы опустите последнее else, это будет менее понятно.

Если ваши дела напрямую не зависят друг от друга, пропустите это:

if (x < 0) {
    return false;
}
if (y < 0) {
    return true;
}
return false;

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

Я предпочитаю второй вариант (отдельный ifsс нет else ifи рано return), НО, который до тех пор, пока блоки кода короткие .

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

Например:

function doSomething(value) {
  if (check1(value)) {
    // ...
    // imagine 200 lines of code
    // ...
    return -1;
  }
  if (check2(value)) {
    // ...
    // imagine 150 lines of code
    // ...
    return value;
  }
  return false;
}

В этом случае лучше использовать else if, хранить код возврата в переменной и иметь только одно предложение возврата в конце.

function doSomething(value) {
  retVal=0;
  if (check1(value)) {
    // ...
    // imagine 200 lines of code
    // ...
    retVal=-1;
  } else if (check2(value)) {
    // ...
    // imagne 150 lines of code
    retVal=value;
  }
  return retVal;
}

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

Я использую оба в разных обстоятельствах. В проверке валидации я опускаю else. В потоке управления я использую остальное.

bool doWork(string name) {
  if(name.empty()) {
    return false;
  }

  //...do work
  return true;
}

против

bool doWork(int value) {
  if(value % 2 == 0) {
    doWorkWithEvenNumber(value);
  }
  else {
    doWorkWithOddNumber(value);
  }
}

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

Единственная ситуация, которую я когда-либо видел, это действительно важно, это код вроде этого:

List<?> toList() {
    if (left != null && right != null) {
        Arrays.asList(merge(left, right));
    }
    if (left != null) {
        return Arrays.asList(left);
    }
    if (right != null) {
        return Arrays.asList(right);
    }
    return Arrays.asList();
}

Здесь явно что-то не так. Проблема в том, что не ясно, returnследует ли добавлять или Arrays.asListудалять. Вы не можете исправить это без более глубокого изучения связанных методов. Вы можете избежать этой неоднозначности, всегда используя полностью исчерпывающие блоки if-else. Эта:

List<?> toList() {
    if (left != null && right != null) {
        Arrays.asList(merge(left, right));
    } else if (left != null) {
        return Arrays.asList(left);
    } else if (right != null) {
        return Arrays.asList(right);
    } else {
        return Arrays.asList();
    }
}

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

Некоторые языки даже не допускают первый стиль. Я стараюсь использовать его только в строго императивном контексте или для предварительных условий в длинных методах:

List<?> toList() {
    if (left == null || right == null) {
        throw new IllegalStateException()
    }
    // ...
    // long method
    // ...
}

Наличие трех выходов из этой функции действительно сбивает с толку, если вы пытаетесь следовать коду и плохо практикуетесь.

Если у вас есть единственная точка выхода для функции, тогда требуются другие.

var result;
if(check1(value)
{
    result = -1;
}
else if(check2(value))
{
    result = value;
}
else 
{
    result = 0;
}
return result;

На самом деле, давайте идти еще дальше.

var result = 0;
var c1 = check1(value);
var c2 = check2(value);

if(c1)
{
    result = -1;
}
else if(c2)
{
    result = value;
}

return result;

Достаточно справедливо, что вы могли бы поспорить за одно раннее возвращение при проверке входных данных. Просто избегайте упаковки всей логики if, если ваша логика в if.

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

Если автор полагал, что утверждение else было необходимо, и, следовательно, не понимал последствий для выражения return для оператора return, то, несомненно, такое отсутствие понимания является основным источником ошибок в этой функции и в целом.