Cómo pasé el verano con C # 8

En un lanzamiento reciente del podcast DotNet & More Blazor, NetCore 3.0 Preview, C # 8 y no solo mencionamos casualmente un tema tan candente como C # 8. La historia sobre la experiencia con C # 8 no fue lo suficientemente grande como para dedicarle un tema por separado, por lo que se decidió compartir con ella los medios del género epistolar.

En este artículo, me gustaría hablar sobre mi experiencia de usar C # 8 en producción durante 4 meses. A continuación puede encontrar respuestas a las siguientes preguntas:

• Cómo "deletrear" en el nuevo C #
• Qué características fueron realmente útiles
• Que decepcionado

Puede encontrar una lista completa de las características de C # 8 en la documentación oficial de Microsoft . En este artículo, omitiré aquellas oportunidades que no podría probar por una razón u otra, a saber:

• Miembros de solo lectura
• Miembros de interfaz predeterminados
• Estructuras de referencia desechables
• Flujos asincrónicos
• Índices y rangos

Propongo comenzar con una de las posibilidades más deliciosas, como me pareció antes.

Cambiar expresiones

En nuestros sueños, presentamos esta función muy optimista:

int Exec(Operation operation, int x, int y) => operation switch { Operation.Summ => x + y, Operation.Diff => x - y, Operation.Mult => x * y, Operation.Div => x / y, _ => throw new NotSupportedException() }; 

Pero, desafortunadamente, la realidad hace sus propios ajustes.
En primer lugar, no hay posibilidad de combinar las condiciones:

  string TrafficLights(Signal signal) { switch (signal) { case Signal.Red: case Signal.Yellow: return "stop"; case Signal.Green: return "go"; default: throw new NotSupportedException(); } } 

En la práctica, esto significa que en la mitad de los casos, la expresión del interruptor tendrá que convertirse en un interruptor regular para evitar copiar y pegar.

En segundo lugar, la nueva sintaxis no admite declaraciones, es decir código que no devuelve un valor. Parecería, bueno, y no es necesario, pero yo mismo me sorprendí cuando me di cuenta de la frecuencia con la que se usa el interruptor (junto con la coincidencia de patrones) para una afirmación en las pruebas.

En tercer lugar, la expresión switch, que se desprende del último párrafo, no admite manejadores de líneas múltiples. Qué miedo entendemos al momento de agregar los registros:

  int ExecFull(Operation operation, int x, int y) { switch (operation) { case Operation.Summ: logger.LogTrace("{x} + {y}", x, y); return x + y; case Operation.Diff: logger.LogTrace("{x} - {y}", x, y); return x - y; case Operation.Mult: logger.LogTrace("{x} * {y}", x, y); return x * y; case Operation.Div: logger.LogTrace("{x} / {y}", x, y); return x / y; default: throw new NotSupportedException(); } } 

No quiero decir que el nuevo interruptor es malo. No, él es bueno, simplemente no lo suficientemente bueno.

Propiedad y patrones posicionales

Hace un año, me parecían los principales candidatos para el título de "oportunidad que cambió el desarrollo". Y, como se esperaba, para utilizar todo el poder de los patrones posicionales y de propiedad, debe cambiar su enfoque de desarrollo. Es decir, es necesario imitar los tipos de datos algebraicos.
Parece que cuál es el problema: toma la interfaz del marcador y listo. Desafortunadamente, este método tiene un serio inconveniente en un proyecto grande: nadie garantiza el seguimiento en tiempo de diseño de la expansión de sus tipos algebraicos. Por lo tanto, es muy probable que con el tiempo, los cambios en el código conduzcan a muchos "fallos en el incumplimiento" en los lugares más inesperados.

Patrones de tuplas

Pero el "hermano menor" de las nuevas posibilidades de comparación con la muestra demostró ser realmente bien hecho. La cuestión es que el patrón de tupla no requiere ningún cambio en la arquitectura familiar de nuestro código, simplemente simplifica algunos casos:

  Player? Play(Gesture left, Gesture right) { switch (left, right) { case (Gesture.Rock, Gesture.Rock): case (Gesture.Paper, Gesture.Paper): case (Gesture.Scissors, Gesture.Scissors): return null; case (Gesture.Rock, Gesture.Scissors): case (Gesture.Scissors, Gesture.Paper): case (Gesture.Paper, Gesture.Rock): return Player.Left; case (Gesture.Paper, Gesture.Scissors): case (Gesture.Rock, Gesture.Paper): case (Gesture.Scissors, Gesture.Rock): return Player.Right; default: throw new NotSupportedException(); } } 

Pero la mejor parte es que esta característica, que es bastante predecible, funciona muy bien con el método Deconstruct. Simplemente pase una clase con Deconstruct implementado para cambiar y usar las capacidades del patrón de tupla.

Usando declaraciones

Parecería una oportunidad menor, pero trae mucha alegría. En todas las promociones, Microsoft habla sobre un aspecto como reducir la anidación. Pero seamos honestos, no tanto lo que importa. Pero lo realmente serio son los efectos secundarios de excluir un bloque de código:

• A menudo, al agregar el uso, tenemos que extraer el código "dentro" del bloque usando el método de copiar y pegar. Ahora simplemente no lo pensamos
• Las variables declaradas dentro del uso y usadas después de Eliminar el objeto que usa son un verdadero dolor de cabeza. Un problema menos
• En las clases que requieren llamadas frecuentes de Dispose, cada método sería 2 líneas más largo. Parecería un poco, pero en la condición de muchos métodos pequeños, este poco no permite mostrar una cantidad suficiente de estos métodos en una pantalla

Como resultado, algo tan simple como usar declaraciones cambia la sensación de codificación tanto que simplemente no desea volver a c # 7.3.

Funciones locales estáticas

Para ser honesto, si no fuera por la ayuda del análisis de código, ni siquiera notaría esta posibilidad. Sin embargo, se estableció firmemente en mi código: después de todo, las funciones locales estáticas son perfectamente adecuadas para el papel de pequeñas funciones puras, ya que no pueden soportar el cierre de las variables del método. Como resultado, es más fácil para el corazón, porque comprende que hay un error potencial menos en su código.

Tipos de referencia anulables

Y para el postre, me gustaría mencionar la característica más importante de C # 8. En verdad, el análisis de tipos de referencia anulables merece un artículo separado. Solo quiero describir las sensaciones.

• En primer lugar, es maravilloso. Podría haber descrito previamente mi intención explícita de declarar un campo o propiedad anulable, pero ahora esta función está integrada en el lenguaje.
• En segundo lugar, no guarda nada de NullReferenceException. Y no estoy hablando de la notoria "obstrucción" en las advertencias. Es solo que en tiempo de ejecución nadie genera ninguna comprobación de argumento nulo para usted, así que no se apresure a lanzar código como lanzar nuevo ArgumentNullException ()
• En tercer lugar, hay un problema grave con el DTO. Por ejemplo, anota una propiedad con el atributo Requerido. En consecuencia, un objeto con una propiedad 100% no nula entrará en su controlador WebAPI. Sin embargo, no es posible asociar este atributo y todos los atributos similares con comprobaciones de tipos de referencia anulables. El caso es que si declaras MyProperty estándar {get; set;} una propiedad con un tipo NotNull, recibirá una advertencia: "[CS8618] La propiedad 'MyProperty' no anulable no está inicializada. Considere declarar la propiedad como anulable" . Lo cual es justo, ya que no puede garantizar una semántica no nula durante el proceso de inicialización. El único resultado de esta característica es la incapacidad de usar propiedades no nulas en cualquier DTO. Pero hay buenas noticias, hay una solución simple: simplemente inicialice su campo con el valor predeterminado:
  

   public string MyProperty { get; set; } = ""; 

• Cuarto, los atributos que manejan casos complejos, como TryGetValue, son bastante complejos. Como resultado, es muy probable que los desarrolladores poco conscientes abusen de los operadores (!), Nivelando así las capacidades de los tipos de referencia anulables. Una esperanza para los analizadores.
• Quinto, y lo más importante, personalmente esta oportunidad ya me ha salvado muchas veces de los errores de NullReferenceException. Resulta un ahorro de tiempo banal: se detectan muchos errores en la etapa de compilación, y no pruebas o depuración. Esto es especialmente cierto no solo en el proceso de desarrollar una lógica empresarial compleja, sino también en el caso de un trabajo trivial con bibliotecas externas, DTO y otras dependencias, que posiblemente contengan valores nulos.

Resumen

Por supuesto, las oportunidades presentadas no alcanzan una revolución completa, pero cada vez hay menos brecha entre C # y F # / Scala. Ya sea bueno o malo, el tiempo lo dirá.

En el momento del lanzamiento de este artículo, C # 8 puede que ya se haya asentado en su proyecto, por lo que me pregunto, ¿qué siente sobre la nueva versión de nuestro idioma favorito?