O “else” deve ser usado em situações em que o fluxo de controle o torna redundante?

Às vezes me deparei com um código semelhante ao exemplo a seguir (o que essa função faz exatamente está fora do escopo desta pergunta):

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

Como você pode ver, if, else ife elseinstruções são utilizados em conjunto com o returncomunicado. Isso parece bastante intuitivo para um observador casual, mas acho que seria mais elegante (da perspectiva de um desenvolvedor de software) descartar o else-s e simplificar o código da seguinte forma:

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

Isso faz sentido, pois tudo o que segue uma returninstrução (no mesmo escopo) nunca será executado, tornando o código acima semanticamente igual ao primeiro exemplo.

Qual das opções acima se encaixa mais nas boas práticas de codificação? Existem desvantagens em qualquer método no que diz respeito à legibilidade do código?

Editar: Uma sugestão duplicada foi feita com esta pergunta fornecida como referência. Acredito que minha pergunta aborda um tópico diferente, pois não estou perguntando sobre evitar declarações duplicadas, como apresentado na outra pergunta. Ambas as questões buscam reduzir as repetições, embora de maneiras ligeiramente diferentes.

Eu gosto do que está sem elsee aqui está o porquê:

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

Porque fazer isso não quebrou nada que não deveria.

Odeie a interdependência em todas as suas formas (incluindo nomear uma função check2()). Isole tudo o que pode ser isolado. Às vezes você precisa, elsemas eu não vejo isso aqui.

Eu acho que depende da semântica do código. Se seus três casos dependem um do outro, indique-o explicitamente. Isso aumenta a legibilidade do código e facilita o entendimento para qualquer outra pessoa. Exemplo:

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

Aqui você está claramente dependendo do valor de xtodos os três casos. Se você omitir o último else, isso seria menos claro.

Se seus casos não dependem diretamente um do outro, omita-o:

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

É difícil mostrar isso em um exemplo simples, sem contexto, mas espero que você entenda meu ponto de vista.

Eu prefiro a segunda opção (separada ifscom no else ife early return), MAS é contanto que os blocos de código sejam curtos .

Se os blocos de código são longos, é melhor usar else if , porque, de outro modo, você não entenderia claramente os vários pontos de saída que o código possui.

Por exemplo:

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;
}

Nesse caso, é melhor usar else if, armazenar o código de retorno em uma variável e ter apenas uma frase de retorno no final.

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;
}

Mas, como alguém deve se esforçar para que as funções sejam curtas, eu diria que seja curta e saia mais cedo, como no seu primeiro trecho de código.

Eu uso os dois em diferentes circunstâncias. Em uma verificação de validação, eu omito o resto. Em um fluxo de controle, eu uso o else.

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

  //...do work
  return true;
}

vs

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

O primeiro caso parece mais como se você estivesse verificando todos os pré-requisitos primeiro, tirando-os do caminho e depois progredindo para o código real que deseja executar. Como tal, o código interessante que você realmente deseja executar pertence diretamente ao escopo da função; é sobre o que realmente trata a função.
O segundo caso é mais parecido com os dois caminhos: um código válido a ser executado que é tão relevante para a função quanto o outro com base em alguma condição. Como tal, eles pertencem em níveis de escopo semelhantes entre si.

A única situação que eu já vi realmente importa é um código como este:

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();
}

Há claramente algo errado aqui. O problema é que não está claro se returndeve ser adicionado ou Arrays.asListremovido. Você não pode corrigir isso sem uma inspeção mais profunda dos métodos relacionados. Você pode evitar essa ambiguidade usando sempre blocos se-else totalmente exaustivos. Este:

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();
    }
}

não será compilado (em idiomas verificados estaticamente), a menos que você adicione retorno explícito primeiro if.

Alguns idiomas nem permitem o primeiro estilo. Eu tento usá-lo apenas em um contexto estritamente imperativo ou para pré-condições em métodos longos:

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

Ter três saídas da função assim é realmente confuso se você estiver tentando seguir o código e praticar mal.

Se você tiver um único ponto de saída para a função, os outros serão necessários.

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

De fato, vamos ainda mais longe.

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

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

return result;

É justo que você possa argumentar sobre um único retorno antecipado da validação de entrada. Apenas evite agrupar todo o lote se sua lógica for um if.

Eu prefiro omitir a declaração else redundante. Sempre que o vejo (na revisão ou refatoração de código), pergunto-me se o autor entendeu o fluxo de controle e se pode haver um erro no código.

Se o autor acreditava que a declaração else era necessária e, portanto, não entendia as implicações do fluxo de controle da declaração de retorno, certamente essa falta de entendimento é a principal fonte de erros, nessa função e em geral.