L’analyse du code revient avec une suggestion de ne pas utiliser & # 8220; out & # 8221; paramètres

Question

J'ai exécuté l'outil d'analyse de code de VS 2008 contre un objet que j'ai créé et j'ai reçu la suggestion suivante ...

  

Avertissement 147 CA1021: Microsoft.Design   : Envisager un design qui ne   exiger que 'returnValue' soit un out   paramètre.

Je découvre & out; " paramètres plutôt utiles et ne se sont pas rendu compte qu’ils étaient considérés comme une pratique mal conçue en matière de conception. Je voulais savoir si quelqu'un pourrait nous éclairer sur la raison pour laquelle j'ai reçu cet avertissement? Si c'est une mauvaise pratique? Pourquoi? et quelle serait la bonne pratique?

J'apprécie vos conseils.

Answer 1

Chaque avertissement d'analyse de code est associé à une documentation à laquelle vous pouvez accéder en le sélectionnant et en appuyant sur F1 . Vous pouvez également cliquer avec le bouton droit sur l'élément pour obtenir de l'aide.

Dans tous les cas, voici la documentation expliquant cet avertissement particulier . .

Je dirais qu'il y a quelques cas où les paramètres out restent un bon choix - en particulier en ce qui concerne l'idiome de codage TryParse, parce que c'est une manière bien établie de faire les choses que la plupart des gens sont supposés comprendre.

En règle générale, il existe de meilleures solutions plus orientées objet pour plusieurs valeurs de retour.

Answer 2

Je me suis déjà lancé dans l'analyse du code de mon projet. De plus, j’ai reçu de nombreuses suggestions perspicaces, j’ai très brièvement désactivé cette option. Beaucoup de suggestions sont de nature religieuse, vous pouvez le faire de cette façon ou d'une autre, une question de style et non une mauvaise pratique.

À votre situation. Si vous ne disposez que d’un paramètre de retour, renvoyez-le hors de la fonction.

Si vous avez également un code de retour qui occupe l'emplacement de retour, envisagez d'utiliser des exceptions pour informer le code de l'appelant des erreurs d'opération.

Si vous devez renvoyer de nombreux paramètres étroitement liés, créez une classe / structure pour les maintenir ensemble et renvoyez-les sous forme de pack.

Answer 3

De nombreux avertissements d'analyse de code me semblent pertinents pour l'écriture de code API que des tiers utiliseront. Votre règle avec des paramètres 'out' est un cas classique: une des raisons pour ne pas les utiliser est que beaucoup d'autres programmeurs ne le sauront pas.

Si elles ne correspondent pas à ce que vous écrivez, désactivez les règles d'analyse de code qui ne vous conviennent pas. Personnellement, j'ai tendance à désactiver les règles de dénomination, de portabilité et d'interopérabilité car elles ne sont pas pertinentes pour le type de code que j'écris.

Answer 4

J'ai désactivé cet avertissement dans la plupart de mes projets. Depuis, je sais que lorsque j'utilise un paramètre out, j'ai une bonne raison de le faire, car j'essaie de les éviter complètement.

Je peux toutefois imaginer que, lorsque vous travaillez avec plusieurs personnes sur un projet, vous souhaitiez activer cet avertissement si vous souhaitez effectuer des révisions de code ...