Cette fonction a-t-elle des valeurs de retour explicites sur tous les chemins de contrôle?

Question

J'ai une fonction step Heaviside centrée sur l'unité pour tout type de données, que j'ai codé en utilisant:

 template <typename T>
int h1(const T& t){
   if (t < 1){
       return 0;
   } else if (t >= 1){
       return 1;
   }
}
 

Lors de l'examen du code, mon critique m'a dit qu'il n'y avait pas de retour explicite sur tous les chemins de contrôle. Et le compilateur ne me prévient pas non plus. Mais je ne suis pas d'accord. les conditions sont mutuellement exclusives. Comment puis-je gérer cela?

Answer 1

Il dépend de la façon dont le modèle est utilisé. Pour un int, vous êtes fine.

Mais, si t est un IEEE754 à virgule flottante double type avec une valeur fixée à l' NaNni t < 1 ni t >= 1 sont true et donc le programme de contrôle a atteint la fin de l' if bloc! Cela provoque la fonction pour retourner sans une valeur explicite; le comportement est indéfini.

(Dans un cas plus général, où T surcharge l' < et >= opérateurs de telle manière à ne pas couvrir toutes les possibilités, le contrôle du programme atteindra la fin de l' if bloc sans explicites return.)

La morale de l'histoire ici est de décider de la direction générale devrait être la valeur par défaut, et faites qu'on l' else des cas.

Answer 2

Tout simplement parce que le code est correct, cela ne veut pas dire qu'il ne peut pas être mieux. L'exécution correcte est la première étape dans la qualité, pas la dernière.

if (t < 1) {
    return 0;
} else if (t >= 1){
    return 1;
}

Le ci-dessus est "correct" pour n'importe quel type de données t qu'est sain d'esprit, un comportement < et >=. Mais ce:

if (t < 1) {
    return 0;
}
return 1;

Est plus facile à voir par l'inspection que chaque cas est couvert, et évite la deuxième inutiles comparaison tout à fait (que certains compilateurs ne pourrait pas avoir optimisé out). Le Code n'est pas seulement lu par les compilateurs, mais par des êtres humains, y compris vous-de 10 ans à partir de maintenant. Donner à l'homme une pause et écrire plus simplement pour leur compréhension.

Answer 3

Comme indiqué, certains numéros spéciaux peuvent être à la fois < et >=, de sorte que votre critique est tout simplement droit.

La question est: que faites vous voulez le code comme ceci en premier lieu? Pourquoi avez-vous même envisager de rendre la vie si difficile pour vous et les autres (les gens qui ont besoin de maintenir votre code)? Juste le fait que vous êtes assez intelligent pour en déduire qu' < et >= devrait couvrir tous les cas ne signifie pas que vous avez à rendre le code plus complexe que nécessaire. Ce qui se passe pour la physique va pour le code de trop: rendre les choses aussi simples que possible, mais pas plus (je crois que Einstein a dit cela).

Pensez à ce sujet. Qu'essayez-vous de réaliser? Doit être quelque chose comme ceci: "Retour 0 si l'entrée est inférieure à 1, renvoyer 1 sinon.' Ce que vous avez fait est d'ajouter de l'intelligence en disant ... oh mais cela signifie que je retourne 1 si t est supérieur ou égal à 1. Ce genre de inutile 'x implique y' est, nécessitant davantage penser à travailler pour le compte du responsable. Si vous pensez que c'est une bonne chose, je vous conseille de faire une couple d'années du code de l'entretien vous-même.

Si c'était mon examen, je voudrais faire une autre remarque. Si vous utilisez un 'si' l'instruction, puis vous pouvez faire ce que vous voulez dans toutes les branches. Mais dans ce cas, vous ne le faites pas "n'importe quoi". Tout ce que vous voulez faire est de retourner la valeur 0 ou 1 selon que t<1 ou pas. Dans ce cas, je pense que le '?:' l'énoncé est beaucoup mieux et plus lisible que l' if déclaration. Donc:

return t<1 ? 0 : 1;

Je sais que l' ?: opérateur est interdit dans certaines entreprises, et je trouve qu'une chose horrible à faire. ?: correspond normalement beaucoup mieux avec les spécifications, et il peut rendre le code donc beaucoup plus facile à lire (si utilisé avec soin) ...