El pattern matching de C# proporciona la capacidad de analizar expresiones para ver si cumplen determinados "patrones" o presentan características determinadas. Podéis ver algunos ejemplos interesantes en el post Un vistazo a los patrones relacionales y combinadores.

Aunque ya los tengo bastante interiorizados y hago uso de ellos cuando toca, todavía no se me ha dado el caso de necesitar los patrones de listas, introducidos hace unos meses en C# 11. Así que no está de más echarles un vistazo para cuando se dé la ocasión 😉

A veces, los problemas de rendimiento de las aplicaciones, o determinadas funcionalidades de ellas, vienen derivados del uso de estructuras incorrectas para almacenar los datos, ya sea en memoria, base de datos o en cualquier tipo de almacén.

En este post vamos a centrarnos en un caso específico que me he encontrado demasiadas veces en código real: el uso indebido del tipo List<T> cuando sólo nos interesa buscar en esta colección por una propiedad que actúa como identificador único del objeto T.

Aunque muchos de nosotros trabajamos a diario con C#, siempre hay algo nuevo por aprender o formas de utilizar algunas características que nunca se nos habían ocurrido. Siempre.

En un nuevo capítulo de la serie de C# bizarro, hoy os planteo un reto sobre este código:

var sum = (int a, int b) => a + b;
var sub = (int a, int b) => a - b;
var mul = (int a, int b) => a * b;
var result = sum - sub + mul;

Console.WriteLine("Resultado: " + result(3, 2));

Resultado: 6

var result = sum - sub + mul;

Otra de las novedades del flamante C# 11 viene a romper una limitación histórica: la ausencia de tipos genéricos en la definición de atributos.

Hasta esta versión del lenguaje, cuando necesitábamos introducir referencias a tipos de datos en un atributo, debíamos pasar obligatoriamente por el uso de un System.Type y el verboso operador typeof(). Además de incómodo, no había forma de limitar los tipos suministrados, dando lugar a errores en tiempo de ejecución que bien podrían haber sido resueltos el compilación con las herramientas apropiadas.

Dicho así quizás sea difícil de entender, pero veámoslo con un ejemplo.

La llegada de C#11 viene acompañada de un buen número de novedades, algunas de ellas bastante jugosas, como los raw string literals o el nuevo modificador "file" que ya hemos ido viendo por aquí.

En esta ocasión, vamos a echar el vistazo a otra de las novedades que pueden resultar de bastante utilidad en nuestro día a día: los miembros requeridos.

Modificadores de visibilidad habituales como internal, public o private nos acompañan desde los inicios de C#, permitiéndonos definir desde dónde queremos permitir el acceso a los tipos que definimos en nuestras aplicaciones. Así podemos indicar, por ejemplo, que una clase pueda ser visible sólo a miembros definidos en su mismo ensamblado, que pueda ser utilizada desde cualquier punto, o que un tipo anidado sólo pueda verse desde el interior de su clase contenedora.

Pues bien, C# 11 traerá novedades al respecto ;)

Disclaimer: lo que vamos a ver aquí es válido en la RC2 de .NET 7, pero aún podría sufrir algún cambio para la versión final, prevista para noviembre de 2022.

Aunque no es algo frecuente ni especialmente recomendable, hay veces que tenemos que introducir en el código algún tipo de lógica, trazas o comprobaciones que solo queremos aplicar mientras depuramos o desarrollamos y, en ningún caso, queremos que vaya a producción.

En estos casos, aparte de anudarnos un lazo en el dedo mientras mantengamos estos cambios para asegurar la eliminación del código de pruebas antes de subir la aplicación a producción, otra idea puede ser utilizar directivas para que este código solo actúe mientras depuramos, o incluso para evitar la compilación exitosa en modo "Release" (el usado normalmente al publicar).

Aún no hemos terminado de asimilar las novedades de C# 10, cuando ya empiezan a llegar noticias de lo que encontraremos en la próxima versión, C# 11, que si todo va bien se lanzará en noviembre de este año.

Una de las que más me ha llamado la atención de momento es la llegada de raw string literals, una característica que mejorará bastante la posibilidad de escribir constantes de cadena multilínea en nuestro código.

Veamos en qué consiste.

Disclaimer: la nueva versión de C# está aún en desarrollo, y detalles de los que veamos aquí podrían cambiar antes de lanzarse definitivamente.

Hace ya mucho tiempo que C# inició un interesante camino para conseguir reducir la cantidad de código necesario para hacer cosas frecuentes, introduciendo la capacidad de hacer implícitas determinadas construcciones y, por tanto, ahorrándonos tiempo y pulsaciones de teclas innecesarias.

En esta línea, todos recordaréis el tipado implícito, que tanto debate abrió en el lanzamiento de C# 3, hace ya casi quince años:

// Antes de C# 3
List<string> strings = new List<string>();

// Usando tipado implícito
var strings = new List<string>();

Bastante tiempo después, ya con C# 10, el lenguaje nos regaló una nueva característica que iba en la misma dirección, las expresiones new con el tipo destino. Éstas permitían construir objetos usando tipado implícito, aunque esta vez en el lado derecho de las expresiones:

// Antes de C# 10
public class MyClass
{
    private Invoice invoice = new Invoice(123);
    private Dictionary<string, Person> people = new Dictionary<string, Person>();
    ...
}

// Ahora
public class MyClass
{
    private Invoice invoice = new (123);
    private Dictionary<string, Person> people = new ();
    ...
}

También en C# 10 nos hemos encontrado con los using globales y using implícitos, características ambas que nos permiten economizar esfuerzos evitando la introducción repetitiva de directivas para la importación de namespaces en el código.

Pues bien, aquí viene la siguiente vuelta de tuerca :) Unas semanas atrás, Immo Landwerth (Program manager de .NET en Microsoft) sorprendía a todos con esta afirmación sobre una de las características principales del próximo C# 11:

Immo Landwerth announcing implicit dots

Parece que uno de los objetivos de C#10 es eliminar código de los archivos de código fuente de C#, simplificando su codificación y lectura. Lo hemos visto con la introducción de características como directivas using globales o los using implícitos: en ambos casos se ahorraba espacio en vertical sustituyendo los using declarados individualmente en cada archivo por directivas aplicadas de forma global al proyecto, bien de forma explícita o implícita.

En cambio, los espacios de nombre con ámbito de archivo o namespace declarations permiten ahorrar espacio en horizontal, evitando un nivel de indentación en el código que la mayoría de las veces es innecesario.

Cuando aparece una nueva versión de C# o .NET, los titulares de las noticias, tweets y posts suelen girar en torno a las novedades más destacadas, aquellas que suponen cambios importantes respecto a versiones anteriores. Pero es habitual que, aparte de éstas, se añadan otras características más pequeñas que muchas veces pasan desapercibidas.

Esto es lo que ocurre con al atributo [CallerArgumentExpression], una joyita de C#10 que puede ayudarnos a hacer más descriptivos los mensajes de error y trazas que guardamos cuando aparece un error en nuestras aplicaciones.

Estamos muy acostumbrados a comenzar nuestros métodos realizando comprobaciones para evitar que pasen a nuestro código valores nulos que pudieran romper la aplicación.

Desde el principio de los tiempos, estas guardas han presentado el siguiente aspecto:

public class MyService
{
    public void MyMethod(object first, object second)
    {
        if(first == null) 
        {
            throw new ArgumentNullException("first");
        }
        if(second == null) 
        {
            throw new ArgumentNullException("second");
        }        
        // ...
    }
}    

¿Todo bien, verdad? El código es aparentemente correcto y fácil de comprender, pero... ¡demasiado extenso! Hemos consumido casi diez líneas de código sólo realizando comprobaciones de "fontanería", y ni siquiera hemos empezado a plantear la funcionalidad real del método.

Afortunadamente, con el tiempo C# ha ido evolucionando y mejorando sucesivamente este escenario tan frecuente.

class Program {
    public static void Main() {
        int f = 0; int x = 0; int y = 0;
        System.Console.WriteLine(
            "{0} {1}",
            f < x,   // is f smaller than x?
            y > (-1) // is y greater than -1?
        );
    }
}

Hace unos días hablábamos de las directivas using globales, un interesante añadido a C# 10 que permite importar espacios de nombres en todos los archivos de código del proyecto, sin necesidad de repetir cientos de veces las mismas líneas en sus encabezados. Simplemente, si un namespace es interesante para nuestro proyecto, lo declaramos como global en algún punto y será lo mismo que si lo hubiéramos hecho en cada uno de los archivos .cs:

global using System;
global using System.Text;
global using System.Text.Json;
global using MyProject.Model;
...

Bien podían haberlo dejado aquí porque ya es una mejora sustancial respecto a lo que tenemos, pero no, el equipo de diseño de C# sigue introduciendo detalles que pueden hacernos la vida más sencilla. Es el caso de los implicit usings que, de la misma forma, acompañan a .NET 6 y C# 10.

Seguro que estáis acostumbrados a ver y escribir las, a veces extensas, listas de directivas using encabezando vuestros archivos de código fuente C#. Aunque ciertamente los entornos de desarrollo actuales son de bastante ayuda a la hora de introducirlos e incluso a veces nos permiten colapsarlos, son unos grandes consumidores del valioso espacio vertical de nuestros monitores:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
// ... (muchos using más)

namespace MyApplication
{
    public class MyClass
    {
        ...
    }
}

Pero si habéis trabajado con Razor, ya sea para crear vistas MVC/Razor Pages o bien desde Blazor, seguro que os habrán encantado los archivos tipo _ViewImports.cshtml o _Imports.razor, pues permiten introducir directivas que se apliquen a todos los archivos Razor del proyecto. 

¿No sería buena idea llevar esto mismo a nivel del lenguaje?

Me encanta que el lenguaje C# vaya introduciendo características que consiguen que cada vez tengamos que escribir menos para conseguir lo mismo, y, sobre todo, si la legibilidad posterior del código no se ve comprometida.

Uno de estos casos son los recientes target-typed new expressions, o expresiones new con el tipo del destino, que básicamente permite evitar la introducción del tipo de datos al usar el constructor de una clase, siempre que el compilador sea capaz de inferirlo por su contexto.

Vamos a echarle un vistazo en este post.

Desde C# 7 podemos emplear patrones en expresiones is o bloques switch para especificar las condiciones que deseamos comprobar, y cada nueva versión del lenguaje sigue introduciendo novedades al pattern matching, haciéndolo cada vez más sencillo y cómodo de utilizar.

En particular, C# 9 ha añadido un montón de características interesantes destinadas a facilitar el uso de patrones, pero en este post vamos a centrarnos en las dos más importantes: los combinadores de patrones y los patrones relacionales.

Hace algunos años hablábamos de que la forma más correcta de determinar si un objeto es nulo en C# era utilizando el operador is:

var invoice = _invoiceRepository.GetById(18);
if(invoice is null) 
{
    // Hacer algo
}

Como vimos en su momento, esta opción era mejor que utilizar una comparación directa como invoice == null porque el operador de igualdad podía ser sobrecargado y, por tanto, su comportamiento podría ser modificado, mientras que el operador is no es sobrecargable.

Sin embargo, al comenzar al usar esta fórmula, encontrábamos un pequeño inconveniente cuando queríamos determinar justo lo contrario, es decir, saber cuándo un objeto no es nulo, pues la sintaxis se volvía algo más pesada:

var invoice = _invoiceRepository.GetById(18);
if(!(invoice is null)) 
{
    // Hacer algo
}

A raíz de los posts sobre generadores de código (como éste y éste), un amigo del blog me escribió para ver si de alguna forma era posible examinar el código fuente generado para poder depurarlo con mayor facilidad.

Y en efecto, es posible. Pero en vez de responderle directamente, he pensado que sería mejor compartirlo por aquí, de forma que pueda resultar de utilidad para alguien más :)

Como decíamos hace unos días, los generadores de código C# nos brindan la posibilidad de crear al vuelo código C# e incluirlo en nuestros proyectos en tiempo de compilación.

Por no alargar demasiado el post, vimos un sencillísimo ejemplo de implementación, pero ahora vamos a crear algo más complejo que podría ayudarnos a solucionar un problema que tendría difícil solución de no contar con esta característica del compilador.

1. Definición de objetivos

El reto al que vamos a enfrentarnos ya lo expusimos en el post anterior como un caso de uso simple de los generadores de código, así que vamos a reproducir la descripción del escenario.

Imaginemos que en nuestra aplicación tenemos clases que representan operadores matemáticos como SumOperator, MultiplyOperator, DivideOperator, SubtractOperator. Imaginad también que nos interesa tener un tipo enum Operators donde aparezca un miembro por cada operador disponible, algo como:

public enum Operators
{
    Sum,
    Multiply,
    Divide,
    Subtract
}

El problema que tiene enfocar esto de forma manual es que resultaría sencillo implementar una nueva clase operador y olvidar crear su correspondiente entrada en la enumeración Operators. Aquí es donde vienen al rescate los generadores de código :)

Lo que implementaremos hoy es un generador de código C# que creará la enumeración por nosotros en tiempo de compilación, manteniéndola sincronizada en todo momento con las clases que tengamos definidas en el proyecto. Para ello, crearemos un generador llamado OperatorsEnumGenerator que:

• En la fase de análisis de código recopilará las clases del proyecto a compilar cuyo nombre finalice por Operator.
• En la fase de generación de código creará el enum con los miembros registrados anteriormente.

¡Vamos allá!