Nunit: Eliminación de la clase Guard

Creado en 24 sept. 2018 · 4Comentarios · Fuente: nunit/nunit

ReSharper y (en los últimos años) Visual Studio sugieren insertar ArgumentNullException y verificaciones de argumentos similares. Es tal la memoria muscular que los he introducido por accidente en la base de código varias veces.

Lanzar directamente es un C# más idiomático desde el punto de vista del análisis de control de flujo. El compilador de C# entiende que no necesita devolver un valor o inicializar una variable antes del uso o romper con un caso de cambio si usa throw lugar de Guard . La verificación de flujo nulo de ReSharper es de la misma manera.

Además, con C# 7.0, las expresiones throw pueden ser convenientes. Por ejemplo, la sintaxis _foo = foo ?? throw new ArgumentNullException(nameof(Foo)); .

¿Cuáles son otras ventajas o desventajas de permitir que los colaboradores y nosotros mismos lancemos excepciones directamente en lugar de usar Guard?

Fuente

jnm2

Comentario más útil

Personalmente, me gusta la clase de guardia, pero estoy de acuerdo en que hay un problema de descubrimiento. Normalmente se lo recomendaría a los colaboradores habituales, pero no se lo mencionaría a los colaboradores puntuales. No creo que esta sea un área en la que particularmente necesitemos consistencia, ¿o sí? Estoy feliz de verlo cuando está allí, pero no me preocupa cuando no lo está.

Soy bastante apático con el resultado de este problema, de cualquier manera está bien para mí 😊

ChrisMaddock en 24 sept. 2018

👍3

Todos 4 comentarios

La principal ventaja de usar la clase Guard es la facilidad de uso, si no recuerdo mal. En un IDE compatible con C#, ya no es la opción más fácil para mí o para los nuevos colaboradores. ¿Necesitamos consistencia, todo en un sentido o en el otro sentido? La consistencia enfrenta lo que es más fácil para algunos de nosotros contra (potencialmente) lo que es más fácil para otros.

jnm2 en 24 sept. 2018

Soy bastante apático con el resultado de este problema, de cualquier manera está bien para mí 😊

ChrisMaddock en 24 sept. 2018

👍3

También soy algo apático al respecto. Proporciona consistencia y el uso correcto de los constructores de excepciones (he visto el mensaje y el nombre del parámetro al revés varias veces), pero también agrega un método adicional a la pila de llamadas. Además, como dices, la nueva sintaxis de C# lo hace mucho más fácil.

No estoy seguro de que necesitemos una purga total, pero estoy de acuerdo con no requerirla.