Maravillas y matices de Resharper

A nadie que haya usado Resharper tengo nada que descubrirle, y a los que no, sólo decirles: Are you from the past? Todos los días aprendo algo nuevo que puede hacer por mí, por ejemplo hoy he descubierto que al borrar líneas dentro de un

elimina automáticamente los espacios y las marcas de comentario /// para facilitar que se unan dos líneas en una (en mi caso, soy muy maniático e intento que los summary ocupen sólo 1 línea, es decir que las etiquetas de inicio y fin estén en la misma línea; salvo que la descripción sea muy larga, claro). Todos los días digo: ¡qué listo es este Resharper! 

El caso que voy a poner es de los buenos: donde Resharper me enseña a usar Linq. No porque no sepa cómo funciona, sino porque muchas veces no se me ocurre aplicarlo, y Resharper me dice: chico, no escribas tanto, si eso puede hacerse con una línea Linq. Y yo le digo: Vale, Resharpito, pero habérmelo dicho antes, que ya lo he escrito 🙂 De todas formas, es conveniente refactorizar y aprender para la próxima.

El caso de hoy tiene un par de matices, y me he decidido a escribirlo. Mi código original era para ver si una colección estaba contenida en otra:

private static bool FiltrosEstrictamenteMasFuertes(IEnumerable cf1, IEnumerable cf2) {
    foreach(var f2 in cf2) {
        bool encontrado = false;
        foreach(var f1 in cf1)
           if(f1.Equals(f2)) {
               encontrado = true;
               break;
           }
           if(!encontrado)
               return false;   //Se ha encontrado un filtro en la segunda colección que no está (igual) en la primera.
        }
    return true;
}

Resharper me pide convertir el foreach interno en una cláusula Linq, y lo acepto:

private static bool FiltrosEstrictamenteMasFuertes(IEnumerable cf1, IEnumerable cf2) {
    foreach(var f2 in cf2) {
        bool encontrado = cf1.Contains(f2);
        if(!encontrado)
            return false;   //Se ha encontrado un filtro en la segunda colección que no está (igual) en la primera.
    }
    return true;
}

Ahora se ve la inutilidad de la variable encontrado, pero sigue ahí, y lo que me propone Resharper es sustituir el otro foreach por otra Linq. De nuevo acepto:

private static bool FiltrosEstrictamenteMasFuertes(IEnumerable cf1, IEnumerable cf2) {
    return cf2.Select(f2 => cf1.Contains(f2)).All(encontrado => encontrado);
}

Ahí está. We did it, lo hicimos. Una sola línea. Pero… ¿que es ese encontrado => encontrado? Cuesta trabajo de entender. Pero si revisamos el paso intermedio anterior, ya comenté que la variable encontrado era prescindible. Si en ese paso la hubiéramos eliminado (de nuevo Resharper, aunque a mano: Ctrl-R, I para Inline variable), la refactorización del foreach nos hubiera producido:

private static bool FiltrosEstrictamenteMasFuertes(IEnumerable cf1, IEnumerable cf2) {
    return cf2.All(f2 => cf1.Contains(f2));
}

Más directo y fácil de entender que el codigo anterior. Ojo, esto no quita méritos a Resharper, aunque por una vez le puedo decir: ¡Toma Resharper! Yo sé más que tú.

Anuncios
Esta entrada fue publicada en Resharper. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s