J'ai dirigé l'outil d'analyse de code VS 2008 contre un objet que j'ai créé et reçu la suggestion suivante ...
Avertissement 147 CA1021: Microsoft.Design : Envisager un design qui ne fait pas exiger que "retourvalue" soit une sortie paramètre.
Je trouve des paramètres «sortis» plutôt utiles et ne réalisaient pas qu'ils étaient considérés comme une pratique de design. Je voulais savoir si quelqu'un pouvait éclairer une lumière 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 tout conseil.
4 Réponses :
J'ai déjà rencontré une analyse de code sur mon projet. Aussi, j'ai eu beaucoup de suggestions perspicaces, j'ai très brièvement éteint ça. Beaucoup de suggestions sont de nature religieuse, vous pouvez le faire de cette manière ou l'autre, une question de style et non une mauvaise pratique.
à votre situation. Si vous n'avez qu'un seul paramètre de retour, retournez-le hors de la fonction.
Si vous avez également un code de retour qui occupe le lieu de retour, envisagez d'utiliser des exceptions pour informer le code de l'appelant des erreurs d'opération.
Si vous avez de nombreux paramètres de retour qui sont étroitement liés les uns aux autres, formez une classe / une structure pour les maintenir et le renvoyer en tant que pack.
Je ne pense pas que ce soit juste d'appeler les règles religieuses de CA. La grande majorité d'entre eux sont basés sur l'analyse de la tentative de la conception de l'API et des études de cas sur ce que les développeurs la plupart comprennent. Les directives de conception du livret de livre ( Amazon.com/framework-design- Lignes directrices-Conventions-Librarerie S / DP / ... ) offre un aperçu beaucoup d'éclairage de ces principes. Il se peut que vous n'acceptais pas de ces règles, et vous êtes certainement libre de ne pas les utiliser, mais ils sont autre chose que «religieux».
@Mark, le problème avec beaucoup de règles de l'autorité de certification, est que l'analyse de la tentative est la manière dont les API publiques lorsque le Vender (Microsoft) ne peut pas obtenir le code Cleint recompanté devrait se comporter. Ce n'est pas le cas avec la plupart des programmes de programmeurs normaux du code.
Chaque alerte d'analyse de code a associé la documentation que vous pouvez accéder à l'avertissement et en appuyant sur F1 . Vous pouvez également cliquer avec le bouton droit de la souris sur l'élément pour obtenir de l'aide.
Dans tous les cas, voici le documentation qui explique cet avertissement particulier .
Je dirais qu'il y a quelques cas où des paramètres sont toujours un bon choix - en particulier lorsqu'il s'agit de la trypairs codant idiome, car c'est une façon aussi bien établie de faire des choses que la plupart des gens sont censés le comprendre
En usage général, toutefois, il existe de meilleures solutions d'objet à plusieurs valeurs de retour.
@Mark: Merci pour l'information et le lien! N'a pas réalisé le F1 Tidbit et le lien explique très bien ce qui se passe. J'apprécie la réponse!
IDIOM TRYPARSE CODING (Exemple: méthode int32.tryparse ) est utile car elle permet de tester une valeur sans avoir à traiter une exception potentiellement une exception. Une exception lancée est calculée en calcul.
J'ai tourné cet avertissement spécifique 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 tout à fait.
Je pouvais imaginer cependant que, lorsque vous travaillez avec plusieurs personnes sur un projet, vous souhaiterez peut-être que cet avertissement soit activé si vous souhaitez faire des critiques de code ...
Bon nombre des avertissements d'analyse de code me semblent être pertinents pour écrire le code de l'API que les 3e parties utiliseront. Votre règle avec les paramètres «Out» est un cas classique: une partie de la raison de ne pas les utiliser est que de nombreux autres programmeurs ne sauront pas d'eux.
S'ils 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 la dénomination, la portabilité et les règles d'interopérabilité, car elles ne sont pas pertinentes pour le type de code que j'écris.
@Lasse: Malheureusement, mon employeur ne me permettra pas de poster des échantillons de code exclusifs. Mes excuses. Je peux dire que la plupart des méthodes ont un type de retour de "Bool" pour indiquer le succès / l'échec et nous utilisons des paramètres "Out" pour renvoyer les données. Merci pour votre réponse!
L'utilisation du type de retour pour indiquer le succès et l'échec est une forme de mauvaise forme ces jours-ci, cependant.