El análisis de código regresa con una sugerencia sobre no usar parámetros de "salida"

Question

Ejecuté la herramienta de análisis de código VS 2008 contra un objeto que creé y recibí la siguiente sugerencia ...

  

Advertencia 147 CA1021: Microsoft.Design   : Considera un diseño que no lo hace.   requiere que 'returnValue' sea un out   parámetro.

Encuentro " fuera " Los parámetros son bastante útiles y no se dieron cuenta de que se consideraban una práctica de diseño mal vista. Quería saber si alguien podría arrojar algo de luz sobre la razón por la que recibí esta Advertencia. Si es mala práctica? ¿por qué? ¿Y qué sería una buena práctica?

Aprecio cualquier consejo.

Answer 1

Cada advertencia de análisis de código tiene documentación asociada a la que puede acceder resaltando la advertencia y presionando F1 . También puede hacer clic con el botón derecho en el elemento para obtener ayuda.

En cualquier caso, aquí está la documentación que explica esa advertencia en particular .

Yo diría que hay algunos casos en los que los parámetros externos todavía son una buena opción, especialmente cuando se trata del lenguaje de codificación TryParse, porque es una forma tan bien establecida de hacer las cosas que la mayoría de las personas deben entenderlo.

En el uso general, sin embargo, existen soluciones mejores y más orientadas a objetos para múltiples valores de retorno.

Answer 2

Una vez ejecuté el análisis de código en mi proyecto. También recibí muchas sugerencias perspicaces, muy brevemente lo apagué. Muchas de las sugerencias son de naturaleza religiosa, puede hacerlo de esta manera u otra, una cuestión de estilo y no una mala práctica.

A tu situación. Si solo tiene un parámetro de retorno, devuélvalo fuera de la función.

Si también tiene un código de retorno que ocupa el lugar de retorno, considere utilizar excepciones para informar al código de la persona que llama sobre los errores de operación.

Si tiene muchos parámetros para devolver que están estrechamente relacionados entre sí, cree una clase / estructura para mantenerlos juntos y devolverlos como un paquete.

Answer 3

Muchas de las advertencias de análisis de código me parecen relevantes para escribir el código API que usarán terceros. Su regla con parámetros 'fuera' es un caso clásico: parte de la razón para no usarlos es porque muchos otros programadores no los conocerán.

Si no coinciden con lo que está escribiendo, desactive las reglas de análisis de código que no le convengan. Personalmente tiendo a desactivar las reglas de nomenclatura, portabilidad e interoperabilidad, ya que no son relevantes para el tipo de código que escribo.

Answer 4

He desactivado esta advertencia específica en la mayoría de mis proyectos. Desde entonces, sé que, cuando uso un parámetro de salida, tengo una buena razón para hacerlo, ya que trato de evitarlos por completo.

Aunque podría imaginar que, al trabajar con varias personas en un proyecto, es posible que desee activar esta advertencia si desea realizar algunas revisiones de código ...