Editorconfig en Visual Studio en 10 minutos o menos

Introducción: Por qué es importante EditorConfig

Tim comienza presentando el proyecto EditorConfig, explicando que la configuración por proyecto es ahora más fácil que nunca de implementar. En lugar de confiar en las preferencias personales guardadas en Visual Studio o en la configuración del editor, ahora puedes configurar un proyecto para mantener un estilo de codificación coherente para todos los colaboradores.

Creación del proyecto

Para demostrar el archivo EditorConfig, Tim crea un nuevo proyecto Blazor Server en Visual Studio. Lo nombra BlazorDemoApp y utiliza la configuración por defecto. Este sencillo proyecto .NET sirve como banco de pruebas para establecer y aplicar la configuración de EditorConfig.

Como explica Tim, este proyecto no necesita lógica ni funcionalidad complejas. Se trata de un ejemplo práctico para trabajar con reglas de estilo de código.

Entender las preferencias de los proyectos y los estilos de codificación

A continuación, Tim explica por qué es importante la configuración a nivel de proyecto. En Visual Studio, cada usuario puede establecer preferencias para aspectos como:

• Uso de tabulaciones o espacios

• El tamaño de la sangría (por ejemplo, 3 o 4 espacios)

• Colocación de llaves {} en la misma línea o en líneas nuevas

• El tipo de declaración de espacio de nombres (por bloques o por archivos)

Estas preferencias suelen almacenarse por usuario en Visual Studio, no por proyecto. Tim destaca que, cuando se trabaja en equipo, la configuración local de cada uno puede diferir. Esto puede dar lugar a formatos de código incoherentes, diferencias innecesarias en los sistemas de control de versiones y pérdida de tiempo al alinear manualmente las preferencias.

Aquí es donde el formato de archivo EditorConfig ayuda: define un conjunto compartido de propiedades EditorConfig que todos los editores de los desarrolladores pueden respetar automáticamente.

Creación y apertura de un archivo EditorConfig

A continuación, Tim muestra cómo añadir un nuevo archivo EditorConfig a la solución.

Hace clic con el botón derecho en la solución y selecciona Añadir → Nuevo EditorConfig. Es posible que Visual Studio arroje un pequeño error al cargar el archivo la primera vez, pero Tim explica que se trata de una peculiaridad inofensiva: basta con cerrar y volver a abrir el archivo.

Este nuevo archivo suele denominarse .editorconfig, y Visual Studio lo reconoce inmediatamente como un documento de configuración. Cabe señalar que Visual Studio admite este archivo de forma nativa, al igual que otros editores de texto como Visual Studio Code e incluso Sublime Text, a través de plugins de editor de texto.

Tim aclara que EditorConfig no es una herramienta exclusiva de Microsoft. Se trata de un estándar de todo el sector que ayuda a los distintos editores a comprender y aplicar las mismas convenciones de codificación, garantizando un formato coherente en múltiples entornos.

Configuración del editorConfiguración de archivos

Una vez que se abre el archivo EditorConfig, Tim explica que extrae la configuración predeterminada de la configuración actual de Visual Studio. No obstante, estas pueden modificarse según sea necesario.

Navega hasta la sección de espacios en blanco, donde se muestra cómo configurarlos:

• Utilice tabulaciones en lugar de espacios

• Ancho de tabulación = 3

Estos son ejemplos de propiedades EditorConfig que definen cómo debe comportarse el formato del código. Una vez guardada, esta configuración se aplica a toda la solución, pero no fuera de ella.

Tim señala que este archivo EditorConfig también puede añadirse a sistemas de control de versiones (como Git), asegurándose de que todos los desarrolladores que clonen el repositorio hereden las mismas reglas. Esto ayuda a mantener un formato coherente independientemente de quién escriba el código.

Trabajar con estilos de código y reglas de espacios de nombres

A continuación, Tim se sumerge en la configuración del estilo del código, concretamente en el estilo de declaración del espacio de nombres.

Por defecto, C# utiliza espacios de nombres de bloque, en los que el espacio de nombres se define con llaves. Tim crea una clase en la carpeta Data para demostrar este formato.

A continuación, cambia la configuración del archivo EditorConfig para utilizar espacios de nombres en archivos. Cuando añade otra clase, Visual Studio aplica automáticamente el estilo actualizado, mostrando el espacio de nombres con un punto y coma (;) en lugar de llaves.

Esto demuestra cómo la configuración de EditorConfig puede influir en las plantillas de generación de código predeterminadas en Visual Studio, alineándose automáticamente con las convenciones definidas del proyecto.

Tim también señala que la función de limpieza de código puede utilizarse para reformatear archivos existentes, garantizando que todo el código se adhiere a las últimas reglas de EditorConfig.

Configuración de la gravedad y aplicación de reglas

En esta sección, Tim se centra en cómo controlar la aplicación de reglas mediante niveles de gravedad en el archivo EditorConfig.

Cada regla puede tener un valor como ninguna, sugerencia, advertencia o error. Tim establece la gravedad de la regla de espacio de nombres en error, e inmediatamente Visual Studio marca cualquier archivo que no coincida con el formato preferido en la ventana Lista de errores.

Esto garantiza que los desarrolladores sigan los estilos definidos y evita desviaciones no deseadas en el archivo actual o en todo el proyecto.

Aunque es posible que aparezcan algunas incoherencias o errores de Visual Studio (como indicaciones de sugerencias erróneas), Tim señala que mejorarán con el tiempo. Lo importante es que las normas se apliquen de forma coherente, haciendo que el código sea fácilmente legible y uniforme.

Múltiples archivos EditorConfig y alcance del directorio

Tim continúa explicando que se pueden tener varios archivos EditorConfig en una única solución.

Por ejemplo:

• Un archivo EditorConfig raíz a nivel de solución define la configuración general para todos los proyectos.

• Un archivo EditorConfig anidado en una subcarpeta como /Data puede anular algunas propiedades (por ejemplo, convenciones de nomenclatura, ancho de tabulación o saltos de línea).

Cada proyecto EditorConfig se comporta jerárquicamente - lo que significa que los archivos en los subdirectorios heredan de los directorios padres, a menos que se anulen explícitamente.

Si desea definir la raíz de su configuración, puede establecer la propiedad root = true en el archivo de nivel superior. Esto le dice a los editores que dejen de buscar en los directorios padre más archivos EditorConfig.

Esta estructura ofrece a los desarrolladores un control detallado de las normas de formato a nivel de proyecto, al tiempo que permite casos especiales en los que podría tener sentido un formato diferente.

Conclusión: Consistencia a través de EditorConfig

En sus observaciones finales, Tim anima a los desarrolladores a utilizar activamente EditorConfig en sus proyectos .NET.

Destaca que este enfoque permite a los equipos mantener reglas de formato, convenciones de nomenclatura y estilos de diseño coherentes, todo ello sin forzar cambios en la configuración personal del editor. Cada archivo abierto sigue automáticamente los estilos definidos en el archivo .editorconfig del proyecto.

Al incluir estos archivos EditorConfig en los sistemas de control de versiones, los equipos se aseguran de que todo el mundo -independientemente de su editor o entorno- se adhiere a las mismas reglas de formato de código.

Tim concluye su vídeo haciendo hincapié en que el formato de archivo EditorConfig es sencillo, flexible y ampliamente compatible. Tanto si utilizas Visual Studio, Visual Studio Code u otro editor de texto, funciona muy bien para ayudar a mantener estilos de codificación coherentes y mantener tu proyecto limpio, profesional y legible.