J'ai un projet sur GITHUB qui est analysé par codacy . L'analyse suggère Quelle est la chose la plus simple scala idiomatique à faire pour le réparer?
5 Réponses :
Si chemin code> peut réellement être em> null code> C'est probablement le plus simple. require(Option(path).isDefined, "Must have a real Path")
chemin! = null fait beaucoup plus de sens que l'option (chemin) .isdefinefinine . Cela accomplit la même chose mais évite une allocation d'objet complètement inutile. Je pense aussi que c'est aussi un peu plus clair.
@Puhlen, je suis d'accord. Je pense aussi que @ pedrorijo91 fait des points valables / précieux. Mais l'OP a demandé le moyen "le plus simple" d'éviter null dans ce scénario et c'est ce que j'ai essayé de fournir.
La manière la plus idiomatique serait d'éviter les besoins (pas sûr, mais j'ai l'idée qu'elle puisse lancer une exception - quelque chose de scala recommande fortement) maintenant le possible Remarque: il est possible que le meilleur endroit pour gérer le boîtier NULL soit à l'intérieur de votre fonction. Dans ce cas, vous devriez faire quelque chose comme
si vous souhaitez conserver le NULL est renvoyé à l'appelant, qui peut / va propager l'option renvoyée jusqu'à ce que le calque sache comment le gérer correctement.
nécessiter , alors le Réponse de JWVH serait mon choix aussi
Cela complique juste inutilement des choses. Au lieu de "faire quelque chose avec le chemin", votre fonction est maintenant "peut-être faire quelque chose avec chemin si vous en donnez un, mais silencieusement pas si vous ne me donnez aucune". Si l'utilisateur souhaite fonctionner avec des options, ils peuvent mapper la fonction d'origine sur leur option eux-mêmes. S'ils ne veulent pas travailler avec des options, ils ne devraient pas avoir à faire Dosomethpath (option (chemin)). Obtenez . Ce n'est même pas vraiment plus sûr, car votre option pourrait être nulle ou même certaines (null).
Je le garderais comme c'est. Vous n'utilisez pas vraiment NULL ici, gardant simplement contre elle. L'alternative pourrait être de supprimer complètement cette ligne et de décider de ne pas gérer le null du tout. Ignorer la possibilité de NULL pourrait aller bien dans une base de code bien construite où elle ne devrait pas venir de toute façon et NULL serait un bug, mais un simple gardien pour attraper cela pourrait empêcher des bugs plus subtils de se présenter au cas où quelque chose s'est mal passé et NULL arrive effectivement.
Il n'est pas nécessaire de vérifier explicitement pour NULL ou Wrap qui retournera une option chemin dans une option .
Vous pouvez le faire: , qui peut ne pas être ce que vous voulez, mais dans ce cas au lieu de produire un Aucun < / code>, soulevez une exception. exiger augmente une exception dans votre exemple de toute façon, si c'est ce que votre appelant s'attend à le faire explicitement.
L'interdiction de ne pas utiliser NULL est une meilleure pratique. Cet article explique pourquoi et GUAVA : Manipulation d'erreurs ad-hoc, ambiguë sémantique, échec lent et ainsi de suite.
L'écriture requise provient de la nécessité d'échouer rapidement et de nettoyer lorsque les conditions préalables à appeler la méthode ne sont pas remplies. Le problème est que cela ne remplace qu'une NPE à une autre exception (néanmoins plus descriptive) car @Puhlen expliqué.
dans un monde idéal Un compilateur Java / Scala doit forcer le type facultatif comme le seul Code qui gère NULL et forcez l'existence de NULL dans le système de frappe. Dans de tels cas, toute utilisation de NULL pourrait être considérée comme une erreur de compilation. Je ne sais pas si cela est complètement réalisable. car il n'y a pas de comportement par défaut de langage / compilateur, vous aurez une incompatibilité d'impédance entre les bibliothèques. Définissez ma propre classe avec PREDEF2 avec une logique minimale de la chaudière. Je n'aurai toujours qu'un seul "évite d'utiliser null" ou utilisez Guava Préconditions.Checknotnull < / p> chemin: chemin sera identique à Number: int et un test de l'existence de l'objet ne sera pas nécessaire. Le problème est que Scala (en tant que pléthora d'autres langues) permet à NULL casser l'approche orientée objet pure. Solution intermédiaire
Utilisation @ nonull / @ nullable annotations
Solution pratique
Envisagez d'accepter l'une des réponses ou de commenter pourquoi vous ne pensez pas qu'ils sont une solution. De cette façon, d'autres utilisateurs qui se retrouvent dans votre question auront plus d'informations sur la manière de résoudre le même problème.