Dovrebbe essere usato "altro" in situazioni in cui il flusso di controllo lo rende ridondante?

A volte inciampo in un codice simile al seguente esempio (ciò che questa funzione fa esattamente non rientra nell'ambito di questa domanda):

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

Come si può vedere, if, else ife le elsedichiarazioni sono utilizzati in combinazione con la returndichiarazione. Questo sembra abbastanza intuitivo per un osservatore occasionale, ma penso che sarebbe più elegante (dal punto di vista di uno sviluppatore di software) eliminare i else-s e semplificare il codice in questo modo:

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

Ciò ha senso, poiché tutto ciò che segue returnun'istruzione (nello stesso ambito) non verrà mai eseguito, rendendo il codice sopra semanticamente uguale al primo esempio.

Quale delle opzioni precedenti si adatta meglio alle buone pratiche di codifica? Ci sono degli svantaggi in entrambi i metodi per quanto riguarda la leggibilità del codice?

Modifica: è stato formulato un suggerimento duplicato con questa domanda fornita come riferimento. Credo che la mia domanda tocchi un argomento diverso, poiché non sto chiedendo di evitare dichiarazioni duplicate come presentato nell'altra domanda. Entrambe le domande cercano di ridurre le ripetizioni, sebbene in modi leggermente diversi.

Mi piace quello senza elseed ecco perché:

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

Perché farlo non ha rotto nulla che non avrebbe dovuto.

Odio l'interdipendenza in tutte le sue forme (inclusa la denominazione di una funzione check2()). Isolare tutto ciò che può essere isolato. A volte ne hai bisogno elsema non lo vedo qui.

Penso che dipenda dalla semantica del codice. Se i tuoi tre casi dipendono l'uno dall'altro, dichiaralo esplicitamente. Ciò aumenta la leggibilità del codice e facilita la comprensione per chiunque altro. Esempio:

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

Qui si dipende chiaramente dal valore di xin tutti e tre i casi. Se omettessi l'ultimo else, questo sarebbe meno chiaro.

Se i tuoi casi non dipendono direttamente l'uno dall'altro, omettilo:

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

È difficile mostrarlo in un semplice esempio senza contesto, ma spero che tu ottenga il mio punto.

Preferisco la seconda opzione (separata ifscon no else ife early return) MA che è purché i blocchi di codice siano brevi .

Se i blocchi di codice sono lunghi, è meglio else ifusarli, perché altrimenti non avresti una chiara comprensione dei vari punti di uscita del codice.

Per esempio:

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

In tal caso, è meglio usarlo else if, memorizzare il codice di ritorno in una variabile e avere solo una frase di ritorno alla fine.

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

Ma come si dovrebbe cercare di abbreviare le funzioni, direi che è breve e si esce presto come nel primo frammento di codice.

Uso entrambi in circostanze diverse. In un controllo di convalida, ometto l'altro. In un flusso di controllo, uso l'altro.

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

Il primo caso dice di più come se stessi controllando prima tutti i prerequisiti, togliendoli di mezzo e poi passando al codice effettivo che desideri eseguire. In quanto tale, il succoso codice che si desidera veramente eseguire appartiene direttamente all'ambito della funzione; è di cosa tratta veramente la funzione.
Il secondo caso è più simile a entrambi i percorsi: codice valido da eseguire che è altrettanto rilevante per la funzione dell'altro in base a una condizione. Come tali, appartengono a livelli di portata simili tra loro.

L'unica situazione che abbia mai visto conta davvero è il codice come questo:

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

C'è chiaramente qualcosa di sbagliato qui. Il problema è che non è chiaro se returndebba essere aggiunto o Arrays.asListrimosso. Non è possibile risolvere questo problema senza un'analisi più approfondita dei metodi correlati. Puoi evitare questa ambiguità usando sempre blocchi if-else completamente esaustivi. Questo:

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

non verrà compilato (in lingue controllate staticamente) a meno che non si aggiunga prima un ritorno esplicito if.

Alcune lingue non consentono nemmeno il primo stile. Cerco di usarlo solo in un contesto strettamente imperativo o per precondizioni in metodi lunghi:

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

Avere tre uscite dalla funzione in quel modo è davvero confuso se stai cercando di seguire il codice attraverso e cattive pratiche.

Se si dispone di un unico punto di uscita per la funzione, sono necessari gli altri.

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

In effetti lascia andare ancora oltre.

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

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

return result;

Abbastanza giusto potresti discutere per un singolo ritorno anticipato sulla convalida dell'input. Evita semplicemente di avvolgere l'intera massa se la tua logica in un if.

Preferisco omettere la dichiarazione di altro ridondante. Ogni volta che lo vedo (in revisione del codice o refactoring) mi chiedo se l'autore abbia compreso il flusso di controllo e che potrebbe esserci un bug nel codice.

Se l'autore ritenesse che la dichiarazione else fosse necessaria e quindi non comprendesse le implicazioni del flusso di controllo della dichiarazione di ritorno, sicuramente una tale mancanza di comprensione è una delle principali fonti di bug, in questa funzione e in generale.