Utiliser 'return' au lieu de 'else' en JavaScript

Question

Je travaille sur un projet qui nécessite un traitement JavaScript assez complexe. Cela inclut beaucoup de imbriqués si - sinon sont situés à plusieurs endroits. En général, j'ai pris le soin d'optimiser le code JavaScript autant que possible en lisant les autres conseils relatifs à Stack Overflow, mais je me demandais si les deux constructions suivantes auraient un impact en termes de vitesse:

if(some_condition) {
    // process
    return ;
}

// Continue the else condition here

vs

if(some_condition) {
    // Process
}

else {
   // The 'else' condition...
}

Answer 1

Je vais toujours avec la première méthode. Plus facile à lire et moins d'indentation. En ce qui concerne la vitesse d'exécution, cela dépendra de la mise en œuvre, mais je m'attendrais à ce qu'ils soient identiques.

Answer 2

Dans de nombreuses langues, il est courant de inverser si instructions pour réduire l'imbrication ou utilisez les conditions préalables .

Et avoir moins d'imbrication dans votre code améliore la lisibilité et la maintenabilité du code.

Answer 3

"Profil, ne spéculez pas!"

1. vous mettez la charrue avant les boeufs (la facilité de maintenance par l'homme surpasse la vitesse de la machine)

2. vous devez diriger vos efforts d'optimisation par des mesures , ce qui signifie

   .
   • vous devriez chronométrer l'exécution vous-même; ça va évidemment différer dans les différents navigateurs et versions
   • vous ne devriez optimiser que les hotspots de votre application (voir le point 1)

Answer 4

Il n'y aura pas de différence de performances. Je recommanderais le deuxième exemple pour la maintenabilité. En général, il est bon d’avoir un et un seul point de sortie possible pour une routine. Cela facilite le débogage et la compréhension.

Answer 5

Je vais utiliser la première approche pour éliminer les situations non valides.

Par exemple. utilisez d'abord l'approche lorsque vous faites des validations, et retournez si l'une des validations échoue. Il ne sert à rien d'aller plus loin si l'une des conditions préalables échoue. Martin Fowler mentionne la même chose dans son livre Refactoring . Il appelle cela "Remplacer les conditions par des clauses de garde". Et cela peut vraiment rendre le code facile à comprendre.

Voici un exemple Java.

  public void debitAccount(Account account, BigDecimal amount) {
    if(account.user == getCurrentUser()) {
      if(account.balance > amount) {
           account.balance = account.balance - amount
       } else {
          //return or throw exception
       }
    } else {
        //return or throw exception
    }
  }

VS

 public void debitAccount(Account account, BigDecimal amount) {
    if(account.user != getCurrentUser()) return //or error
    if(account.balance < amount) return //or error
    account.balance = account.balance - amount    
}

Answer 6

Peut-être un peu, mais je ne pense pas que ce sera mesurable à moins que le reste de la fonction implique "lourd" (et sinon redondant puisque je suppose qu'un retour donnerait le même résultat) js appelle.

En passant, je pense qu'il s'agit d'une micro-optimisation inutile et que vous devriez probablement chercher ailleurs des améliorations en termes de performances, telles que le profil du script via les outils de développement de Chrome ou Firebug pour Firefox (ou des outils similaires), puis une exécution lente / longue. appels / fonctions.

Answer 7

Bien que cela dépende de l'implémentation JavaScript du navigateur en cours d'exécution, il ne devrait pas y avoir de différence notable entre eux (en termes de vitesse).

La deuxième forme est préférable car interrompre le flux n’est pas une bonne habitude de programmation. Pensez également à cela dans l’assemblage, l’instruction de saut (micro opération) est toujours évaluée quelle que soit l’évaluation.

Answer 8

Testez-le vous-même. Si ce code JavaScript est exécuté dans le navigateur, il est presque certain que cela dépendra du moteur d’analyse JavaScript du navigateur.

Answer 9

Je crois comprendre que cela ne ferait aucune différence, car vous créez une branche avec la condition if. Donc, si une condition est vraie, la partie "autre" ne sera pas touchée, même sans le retour.

Answer 10

Supposons que le return prenne 1 ms par rapport au imbriqué si prenait 0.1 ms (ou inversement).

Il est difficile d’imaginer que l’un ou l’autre soit presque aussi lent.

Maintenant, le faites-vous plus de 100 fois par seconde?

Si oui, peut-être devriez-vous vous en soucier.

Answer 11

Lorsqu'il n'y a qu'un seul if..else la performance est presque la même et peu importe. Utilisez ce qui est le mieux lisible dans votre cas. Mais arriver aux instructions imbriquées en utilisant return est le most performant comparé à si ... sinon et commutateur de casse

Answer 12

D'après mes expériences, cela dépend de la condition que vous vérifiez.

1. if .. return est simple et facile à lire si vous vérifiez une condition booléenne (peut-être un paramètre) qui rendrait tout le code suivant inutile pour qu'il soit exécuté.

2. if .. else est beaucoup plus facile à lire si vous vous attendez à ce qu'une valeur soit deux (ou plus) possibles et si vous souhaitez exécuter un code différent pour les deux cas. Cela signifie que les deux valeurs possibles représentent des conditions de valeur interprétable égale et doivent donc être écrites sur le même niveau logique.

Answer 13

À mon avis, return et else sont les mêmes pour le cas ci-dessus, mais en général if-else et if () return; sont très différents. Vous pouvez utiliser l'instruction return lorsque vous souhaitez passer de la portée actuelle à la portée parent. Dans le cas de if-else , vous pouvez rechercher d'autres if-else dans la même portée.