Le migliori pratiche nell'impostazione del valore di ritorno (usare altro o?)

Question

Le migliori pratiche nell'impostazione del valore di ritorno (usare altro o?)

#1 da (10 voti)
#2 da (8 voti)
#3 da (5 voti)
#4 da (4 voti)
#5 da (4 voti)
#6 da (1 voti)

6

Ogni volta che vuoi restituire un valore da un metodo, ma qualunque cosa tu restituisca dipende da qualche altro valore, di solito usi la ramificazione:

int calculateSomething() {
  if (a == b) {
    return x;
  } else {
    return y;
  }
}

Un altro modo per scrivere questo è:

int calculateSomething() {
  if (a == b) {
    return x;
  }
  return y;
}

C'è qualche ragione per evitare l'uno o l'altro? Entrambi consentono di aggiungere "else if" -la scrittura senza problemi. Entrambi in genere generano errori del compilatore se aggiungi qualcosa in fondo.

Nota: non sono riuscito a trovare duplicati, sebbene esistano più domande sul fatto che le parentesi graffe che accompagnano devono essere sulla propria linea. Quindi non entriamo in questo.

coding-style

posta Deckard 29.06.2011 - 09:52

fonte

6 risposte

10

Preferisco un terzo approccio, specialmente quando si tratta di booleani:

int calculateSomething() { 
    int value = y; // whatever the default value is
    if (a == b) { 
        value = x;
    }

    return value;
}

Trovo più naturale il fatto che non si abbiano dichiarazioni di ritorno ovunque nel flusso logico, tuttavia ci sono momenti in cui è meglio usare il secondo modulo. Quanto sopra è solo la mia preferenza per impostazione predefinita.

risposta data 29.06.2011 - 14:40

fonte

5

Preferisco avere una clausola di ritorno che non sia all'interno di un loop, if o else-branch. Pertanto, opto per la seconda versione.

La mia ragione: in PL / SQL (e probabilmente anche in altri linguaggi), il compilatore non nota l'omissione di un'istruzione return, ma il programma genera un'eccezione se una funzione non termina con un'istruzione return esplicita.

risposta data 29.06.2011 - 10:39

fonte

4

Come dice Lenny222 nei commenti, è davvero solo una questione di gusti .

Personalmente preferisco il secondo modulo, poiché è

più conciso
meglio leggibile (imo)

Penso che la clausola else nella prima forma sia semplicemente ridondante, e quindi aggiunge confusione.

risposta data 29.06.2011 - 10:28

fonte

4

In Java puoi scrivere:

int calculateSomething() { 
    return a == b ? x : y;
}

risposta data 01.08.2011 - 15:54

fonte

1

Non ha senso utilizzare else dopo return .

Gli standard di codifica LLVM dicono lo stesso:

...do not use 'else' or 'else if' after something that interrupts control flow — like return, break, continue, goto, etc. For example, this is bad:
case 'J': {
  if (Signed) {
    Type = Context.getsigjmp_bufType();
    if (Type.isNull()) {
      Error = ASTContext::GE_Missing_sigjmp_buf;
      return QualType();
    } else {
      break;
    }
  } else {
    Type = Context.getjmp_bufType();
    if (Type.isNull()) {
      Error = ASTContext::GE_Missing_jmp_buf;
      return QualType();
    } else {
      break;
    }
  }
}
...The idea is to reduce indentation and the amount of code you have to keep track of when reading the code.

risposta data 07.12.2011 - 16:12

fonte

Leggi altre domande sui tag coding-style

Le tabelle del database devono avere ID? Prova legale di quando una funzionalità è stata implementata [chiusa]

score 8 · Accepted Answer

Uso entrambi, a seconda del metodo. Ad esempio, in un metodo che decide qualcosa, penso che

public boolean isSunday(Calendar cal) {
  if (Calendar.SUNDAY == cal.get(Calendar.DAY_OF_WEEK))
    return true;
  else
    return false;
}

cattura meglio l'intento del metodo. È senza stato, non dovrebbe essere esteso ed è chiuso in quanto la clausola if genera tutti i valori che il metodo potrebbe mai restituire.

Se il metodo calcola qualcosa o recupera informazioni, mi piace la seconda variante di più:

public String getAnswer(int question) {
  if (isAvailable(preciseAnswerService)
    return preciseAnswerService.answer(question);
  return defaultAnswer(question);
}

Qui, il fatto che una risposta sia scelta rispetto all'altra dipende dallo stato della answerService. Potremmo estendere il metodo in un secondo momento aggiungendo un preciso AnswerCache o recuperando la risposta da qualche altra parte.