Eliminando i casi cattivi in se ottenere un codice migliore

Le risposte nella domanda collegata, considerate nel loro insieme, ammontano a dipende. Spesso è preferibile avere un unico punto di ritorno, ma ci sono momenti in cui il ritorno anticipato semplifica enormemente il codice. L'errore sarebbe fare affidamento su una regola di tipo meccanico piuttosto che concentrarsi su un buon design.

Lo stesso vale per il tuo caso. Non c'è motivo di preferire sempre controllare se qualcosa è vero piuttosto che verificare se è falso. Devi pensare a ciò che costituisce un buon design in ogni caso specifico .

if (!something) può essere leggermente meno chiaro di if (something) , in particolare quando si verifica più di una singola condizione. Tuttavia, il refactoring del codice in modo che tutti i condizionali controllino la verità potrebbe rendere il codice molto meno comprensibile nella pratica.

Come punto di partenza, proverei a scriverlo nel modo in cui descriverò intuitivamente cosa sta facendo la funzione .

we should always check the the conditions under which we should DO staff rather than trying to eliminate all the bad cases.

No.

Se ciò fosse vero, non ci sarebbe nulla come Clausole di protezione , e le clausole di salvaguardia sono considerate best practice.

Detto questo, le clausole di guardia sembrano un po 'diverse in Javascript rispetto ad altri linguaggi di programmazione, a causa della presenza di funzioni di prima classe e del ruolo unico che la funzione scoping ha in Javascript.

Ulteriori letture
Operatori di protezione e predefiniti in Javascript
No ifs ... alternative a istruzione ramificata in JavaScript

I casi sono correlati. Tuttavia, né il primo né il secondo approccio sono pessimi.

In uno scenario ideale, le tue funzioni non sono più di poche righe, il che significa che in fondo non importa se usi il primo o il secondo approccio, poiché entrambi sono molto facili da leggere.

Il problema si verifica quando ti ritroverai con una funzione molto lunga, che di solito significa che qualcosa non è giusto nel tuo codice e che probabilmente dovrebbe essere refactored.

Pur mantenendo le funzioni separate, semplice, dipende principalmente da te se utilizzare una precoce istruzione return o fare un blocco di guardia if .

Personalmente, mi piace un po 'meglio return , perché quando esci dalla funzione, non è necessario eseguire la scansione del resto chiedendo se un'altra parte di codice non altera il risultato.