Est un principe de style de codage - par exemple le principe de sortie unique
Les gens qui se demandent encore s'il s'agit d'une sortie unique ou de sorties multiples sont toujours bloqués à la fin des années 1960. À l'époque, une telle discussion était importante car nous étions dans les balbutiements du programmeur structuré, et il y avait un camp assez nombreux proclamant que les découvertes derrière le théorème du programme structuré de Bohm-Jacopini n'étaient pas universellement applicables à toutes les constructions de programmation.
C'est quelque chose qui aurait dû être réglé depuis longtemps. Eh bien, c'est réglé (près de 4 décennies pour être précis, à la fois dans le monde universitaire et dans l'industrie), mais les gens (ceux qui sont absolument pro ou contre) n'ont pas fait attention.
Quant au reste de mes réponses, tout est relatif (qu'est-ce qui n'est pas dans le logiciel?):
- vraiment une bonne chose?
Oui. La plupart du temps pour le cas général, avec des mises en garde spécifiques aux cas marginaux et des constructions de programmation spécifiques au langage.
Toujours ou juste parfois?
Le plus souvent.
Quelle différence cela fait-il vraiment?
Dépend.
Code lisible vs code illisible. Complexité accrue (que nous devrions connaître maintenant augmente la probabilité d'introduction d'erreurs) vs complexité plus simple (et ergo, probabilité d'erreurs plus faible). Langages dont les compilateurs n'ajoutent pas de retour implicite (par exemple, Pascal, Java ou C #) et ceux qui par défaut à int (C et C ++).
En fin de compte, c'est une compétence affinée avec des heures / homme derrière un clavier. Parfois, c'est correct d'avoir plusieurs instructions de retour, comme ici (dans certains pseudocodes Pascal'esque):
function foo() : someType
begin
if( test1 == true )
then
return x;
end
doSomethignElseThatShouldnHappenIfTest1IsTrue();
return somethingElse();
end;
L'intention est claire, et l'algorithme est suffisamment petit et assez simple pour qu'il ne justifie pas la création d'une variable «drapeau» qui contient la valeur de retour éventuelle utilisée dans un seul point de retour. L'algorithme peut être erroné, mais sa structure est suffisamment simple pour que l'effort de détection d'une erreur soit (très probablement) négligeable.
Parfois, ce n'est pas le cas (en utilisant ici un pseudocode de type C):
switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
doSomething(); // no return statement yet
}
Ici, l'algorithme n'a pas de structure simple et l'instruction switch (de style C) permet des étapes de passage qui peuvent ou non être effectuées intentionnellement dans le cadre de l'algorithme.
Peut-être que l'algorithme est correct, mais mal écrit.
Ou peut-être, par des forces externes au-delà des capacités du programmeur, c'est la représentation réelle (et correcte) d'un algorithme légitimement nécessaire.
C'est peut-être faux.
Pour découvrir la vérité de tout cela, il faut beaucoup plus d'efforts que dans l'exemple précédent. Et là se trouve quelque chose que je crois fermement (sachez que je n'ai aucune étude formelle à l'appui):
En supposant un extrait de code supposé correct:
Les instructions de retour multiples augmentent la lisibilité et la simplicité d'un tel extrait de code, si l'extrait de code représente un algorithme simple avec une structure de flux intrinsèquement simple. Par simple, je ne veux pas dire petit, mais je veux dire intrinsèquement compréhensible ou évidence , ce qui ne nécessite pas d'effort de lecture disproportionné (ni inciter les gens à vomir, à maudire la mère de quelqu'un ou à avaler une balle quand ils doivent le lire. )
Une seule déclaration de retour augmente la lisibilité et la simplicité d'un tel morceau de code si la valeur de retour est calculée tout au long de l'exécution de l'algorithme ou si les étapes de l'algorithme chargé de le calculer peuvent être regroupées en un seul emplacement dans la structure de l'algorithme .
Une seule instruction de retour diminue la lisibilité et la simplicité d'un tel morceau de code si elle nécessite des affectations à une ou plusieurs variables d'indicateur, les emplacements de ces affectations n'étant pas uniformément situés dans tout l'algorithme.
Les instructions de retour multiples réduisent la lisibilité et la simplicité d'un tel morceau de code si les instructions de retour ne sont pas réparties uniformément dans l'algorithme et si elles délimitent des blocs de code mutuellement exclusifs qui ne sont pas de taille ou de structure uniformes entre eux.
Cela est étroitement lié à la complexité d'un extrait de code en question. Et ceci est à son tour lié aux mesures de complexité cyclomatiques et halstead. De cela, on a pu observer ce qui suit:
Plus la taille d'un sous-programme ou d'une fonction est grande, plus sa structure de flux de contrôle interne est grande et complexe, et plus vous serez confronté à la question d'utiliser ou non des instructions de retour multiples ou complexes.
La conclusion de ceci est: gardez vos fonctions petites en faisant une seule et unique chose (et en le faisant bien). S'ils présentent des métriques de complexité cyclomatique et halstead nominalement réduites, non seulement ils sont très probablement corrects et implémentent des tâches qui sont compréhensibles, mais leurs structures internes seront également relativement évidentes.
Ensuite, et seulement alors, vous pouvez assez facilement et sans perdre beaucoup de sommeil, vous pouvez décider d'utiliser un seul retour et plusieurs retours sans courir beaucoup de risques d'introduire des erreurs avec l'un ou l'autre choix.
On pourrait également examiner tout cela et suggérer que lorsque les gens sont aux prises avec la question des retours uniques ou des retours multiples, c'est parce que - soit par inexpérience, par stupidité ou par manque d'éthique du travail - ils n'écrivent pas de code propre et ont tendance à écrire fonctions monstrueuses avec mépris total des mesures cyclomatiques et halstead.