¿Por qué las pautas de .Net recomiendan que no use argumentos de ref / out?

Question

Al parecer, son "confusos". ¿Es esa la razón seriamente? ¿Se te ocurren otros?

Answer 1

¿Has visto cuántos desarrolladores realmente no entienden ref / out?

Los uso donde son realmente necesarios, pero no de otra manera. Por lo general, solo son útiles si desea devolver efectivamente dos o más valores, en cuyo caso vale la pena al menos pensar sobre si hay una forma de hacer que el método solo haga una cosa en su lugar. A veces, usar ref / out es el enfoque más apropiado: los diversos métodos TryParse, etc.

Answer 2

En mi opinión, se consideran un olor de código porque, en general, hay una opción mucho mejor: devolver un objeto.

Si observa, en la biblioteca .NET solo se usan en algunos casos especiales, como tryparse , como escenarios en los que:

• devolver una clase significaría encasillar un tipo de valor
• el contrato del método requiere que sea rápido, por lo que el boxeo / unboxing no es una opción viable.

Answer 3

ref / out significa automáticamente mutabilidad, y la programación funcional con valores inmutables está de moda en estos días. Intente insertar una llamada a Dictionary.TryGetValue en una consulta LINQ. La API requiere declarar variables y arruina cualquier 'fluidez' en la API.

Eso no quiere decir que esta sea la "razón", sino que es un ejemplo de "una razón".

(Ver también

http://lorgonblog.spaces.live.com/blog /cns!701679AD17B6D310!181.entry

para comentarios sobre cómo los lenguajes funcionales manejan tales API.)

Answer 4

La confusión es probablemente la mejor razón. Confundir significa una menor capacidad de mantenimiento y una mayor probabilidad de introducir errores sutiles. Los veo en una vista similar a la de " goto " Declaración de flujo de control. Si bien no es intrínsecamente malo por sí solo, ha llevado a muchos programas imposibles de leer / entender a lo largo de las décadas.

Manténgase alejado de cualquier cosa que pueda hacer que su código sea más confuso de lo que debe ser.

Habiendo dicho eso, esas palabras clave existen probablemente porque los desarrolladores del framework vieron la necesidad de tales cosas. Utilícelos si no hay una solución adecuada, pero evítelos cuando pueda.

Answer 5

ref / out tampoco funciona con " Func " delegados, por lo que estas API de estilo son menos compuestas / reutilizables con otras API que usan delegados.

Answer 6

Solo un pensamiento, encuentro que ref / out es útil cuando los argumentos capturan el estado de ejecución en el método de destino en lugar de capturar los datos devueltos. Considere un escenario cuando desee obtener un mensaje de error de un servicio que devuelva el objeto Cliente.

Customer GetCustomerById(int id, out string errorMessage);

Si este método falla, probablemente devolvería un objeto de Cliente nulo o lanzaría una excepción. Sin embargo, si quiero saber la causa del error (¿validación? ¿Base de datos?), Usaría un argumento. El argumento errorMessage aquí no tiene nada que ver con los datos, simplemente se utiliza para capturar lo que está mal con la ejecución del método.

Personalmente, si tengo un método que se espera que devuelva dos o más datos / valores esenciales, repensaría el diseño de mi código.

Answer 7

El motivo por el que me informaron es que el 1.0 GC tuvo problemas cuando se usó ref / out. El GC en 2.0 (y probablemente tampoco el 1.1) no tiene esos problemas, por lo que normalmente asumo que ahora es un legado no útil.

Answer 8

@TraumaPony Estaría bien si nos diera una fuente (URL o algo) a esta guía de .NET framework.

Answer 9

Es probable que la devolución de objetos sea la razón más probable por la que sugieren no usar ref o out.

" ref " en realidad, solo se necesita usar cuando se pasan valores escalares, pero veo que la gente lo usa a menudo para los objetos que se pasan por referencia de todos modos.

Answer 10

¿No es suficiente la razón de la complejidad del código? Comparar:

int myValue;
ReadFromSomewhere(ref myValue);

Para:

int myValue = ReadFromSomewhere();