J'ai toujours entendu dire qu'une fonction à point de sortie unique était une mauvaise façon de coder car on perd en lisibilité et en efficacité. Je n'ai jamais entendu personne défendre l'autre côté.
Je pensais que cela avait quelque chose à voir avec CS mais cette question a été rejetée par cstheory stackexchange.
Il existe différentes écoles de pensée, et c'est surtout une question de préférence personnelle.
La première est qu'il est moins difficile de s'y retrouver s'il n'y a qu'un seul point de sortie - vous avez un seul chemin à suivre dans la méthode et vous savez où chercher la sortie. En revanche, si vous utilisez l'indentation pour représenter l'imbrication, votre code se retrouve massivement indenté vers la droite, et il devient très difficile de suivre tous les scopes imbriqués.
Un autre avantage est que vous pouvez vérifier les conditions préalables et sortir de manière anticipée au début d'une méthode, de sorte que vous savez dans le corps de la méthode que certaines conditions sont vraies, sans que le corps entier de la méthode soit indenté à 8 km sur la droite. Cela minimise généralement le nombre de scopes dont vous devez vous préoccuper, ce qui rend le code beaucoup plus facile à suivre.
Une troisième est que vous pouvez sortir où bon vous semble. Autrefois, cela prêtait à confusion, mais maintenant que nous disposons d'éditeurs à coloration syntaxique et de compilateurs qui détectent le code inaccessible, c'est beaucoup plus facile à gérer.
Je suis carrément dans le camp du milieu. Imposer un point de sortie unique est une restriction inutile, voire contre-productive, à mon avis, alors que sortir au hasard dans toute une méthode peut parfois conduire à une logique désordonnée et difficile à suivre, où il devient difficile de voir si un bout de code donné sera ou ne sera pas exécuté. Mais "gating" votre méthode permet de simplifier significativement le corps de la méthode.
Ma recommandation générale est que les déclarations de retour devraient, lorsque cela est possible, être situées avant le premier code qui a des effets secondaires, ou après le dernier code qui a des effets secondaires. J'envisagerais quelque chose comme :
if (!argument) // Check if non-null
return ERR\_NULL\_ARGUMENT;
... process non-null argument
if (ok)
return 0;
else
return ERR\_NOT\_OK;plus clair que :
int return\_value;
if (argument) // Non-null
{
.. process non-null argument
.. set result appropriately
}
else
result = ERR\_NULL\_ARGUMENT;
return result;Si une certaine condition empêche une fonction de faire quoi que ce soit, je préfère sortir de la fonction à un endroit situé au-dessus du point où la fonction ferait quelque chose. Cependant, une fois que la fonction a entrepris des actions ayant des effets secondaires, je préfère revenir par le bas, afin d'indiquer clairement que tous les effets secondaires doivent être traités.
Le point d'entrée et de sortie unique était le concept original de la programmation structurée par rapport au codage spaghetti étape par étape. On pense que les fonctions à points de sortie multiples nécessitent plus de code car il faut nettoyer correctement les espaces mémoire alloués aux variables. Considérez un scénario où la fonction alloue des variables (ressources) et où sortir de la fonction tôt et sans nettoyage approprié entraînerait des fuites de ressources. En outre, la construction du nettoyage avant chaque sortie créerait beaucoup de code redondant.
Pour la plupart des choses, tout dépend des besoins du produit à livrer. Dans le "bon vieux temps", le code spaghetti avec de multiples points de retour invitait à des fuites de mémoire, car les codeurs qui préféraient cette méthode ne nettoyaient généralement pas bien. Certains compilateurs pouvaient également "perdre" la référence à la variable de retour lorsque la pile était vidée pendant le retour, dans le cas d'un retour à partir d'une portée imbriquée. Le problème plus général était celui du code ré-entrant, qui tente de faire en sorte que l'état d'appel d'une fonction soit exactement le même que son état de retour. Les mutateurs de oop ont violé ce principe et le concept a été mis de côté.
Certains produits livrables, notamment les noyaux, ont besoin de la rapidité qu'offrent les points de sortie multiples. Ces environnements ont normalement leur propre gestion de la mémoire et des processus, de sorte que le risque de fuite est minimisé.
Personnellement, j'aime avoir un point de sortie unique, car je l'utilise souvent pour insérer un point d'arrêt sur l'instruction de retour et effectuer une inspection de code sur la façon dont le code a déterminé cette solution. Je pourrais simplement aller à l'entrée et passer à travers, ce que je fais avec des solutions largement imbriquées et récursives. En tant que réviseur de code, les retours multiples dans une fonction nécessitent une analyse beaucoup plus approfondie - donc si vous le faites pour accélérer l'implémentation, vous volez Pierre pour sauver Paul. Il faudra consacrer plus de temps à l'examen du code, ce qui invalidera la présomption d'une mise en œuvre efficace.
-- 2 cents
Veuillez consulter ce document pour plus de détails : NISTIR 5459
Si vous avez l'impression d'avoir besoin de plusieurs points de sortie dans une fonction, c'est que la fonction est trop grande et qu'elle en fait trop.
Je vous recommande de lire le chapitre sur les fonctions dans le livre de Robert C. Martin, Clean Code.
Essentiellement, vous devez essayer d'écrire des fonctions avec 4 lignes de code ou moins.
Quelques notes de Blog de Mike Long :
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
