Inversant le « if » améliore-t-il la performance ?

Question

J'utilise ReSharper depuis un moment maintenant et parfois il suggère que j'inverse le if . Je suppose qu'un exemple serait une meilleure explication de ma situation:

 public void myfunction(int exampleParam){
    if(exampleParam > 0){
        //Do something with form controls for example.
    }
}
 

Maintenant, ReSharper suggère que j'inverse le if à ceci:

 public void myfunction(int exampleParam){
    if(exampleParam <= 0)
        return;
    //Do something with form controls for example
}
 

Est-ce que cela "améliore" la performance en quelque sorte? Ou est-ce juste esthétique?

Answer 1

Il n'est pas seulement esthétique, mais il réduit également le maximum de niveau d'imbrication à l'intérieur de la méthode. Cela est généralement considéré comme un plus, car il rend les méthodes les plus faciles à comprendre (et en effet, de nombreux statique de l'analyse des outils de fournir une mesure de ce que l'un des indicateurs de la qualité du code).

D'autre part, il rend également votre méthode ont de multiples points de sortie, quelque chose qu'un autre groupe de gens croient est un non-non.

Personnellement, je suis d'accord avec ReSharper et le premier groupe (dans une langue qui a des exceptions je trouve ça ridicule de discuter de plusieurs points de sortie"; presque tout peut jeter, il y a donc de nombreuses potentiel des points de sortie dans toutes les méthodes).

Concernant les performances: les deux versions devraient être équivalentes (si ce n'est pas le niveau IL, alors certes, après la gigue est via le code) dans toutes les langues. Théoriquement, cela dépend du compilateur, mais pratiquement n'importe quel largement utilisé compilateur d'aujourd'hui est capable de gérer beaucoup plus de cas avancés d'optimisation de code que cela.

Answer 2

Comme d'autres l'ont mentionné, il ne devrait pas être un gain de performance, mais il y a d'autres considérations. En dehors de ces préoccupations légitimes, cela peut aussi vous ouvrir à de pièges dans certaines circonstances. Supposons que l'on vous traite avec un double à la place:

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

Voilà qui contraste avec l' apparence de l'équivalent d'inversion:

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

Donc, dans certaines circonstances, ce qui semble être une bonne inversé if peut-être pas.

Answer 3

Je voudrais ajouter qu'il y a un nom pour ceux qui sont inversés si - la clause de garde. Je l'utilise quand je peux.

Je déteste lire le code où il y a si au début, deux écrans de code et pas d'autre. Juste inverser si et retourner. De cette façon, personne ne perdra son temps à défiler.

http://c2.com/cgi/wiki?GuardClause

Answer 4

Cela n'affecte pas seulement l'esthétique, mais empêche également l'imbrication du code.

Il peut en fait fonctionner comme une condition préalable pour garantir que vos données sont également valides.

Answer 5

En terme de Performance, il n'y aura pas de différence notable entre les deux approches.

Mais le codage est plus que de la performance. La clarté et la facilité de maintenance sont également très importants. Et, dans des cas comme celui-ci où il n'affecte pas les performances, c'est la seule chose qui compte.

Il y a des écoles concurrentes de la pensée, pour ce qui est préférable.

Un point de vue est celui d'autres ont mentionné: la deuxième approche permet de réduire le niveau d'imbrication, ce qui améliore le code de la clarté. Ce qui est naturel dans un impératif de style: quand vous n'avez plus rien à faire, vous pourriez aussi bien revenir plus tôt.

Un autre point de vue, de la perspective d'une plus fonctionnelles de style, est que la méthode doit avoir qu'un seul point de sortie. Le tout dans un langage fonctionnel est une expression. Donc, si les instructions doivent toujours avoir une autre des clauses. Sinon, si l'expression ne serait pas toujours une valeur. Ainsi, dans le style fonctionnel, la première approche est plus naturel.