Editorconfig dans Visual Studio en 10 minutes ou moins

Introduction : Pourquoi EditorConfig est important

Tim commence par présenter le projet EditorConfig, en expliquant que les paramètres par projet sont désormais plus faciles que jamais à mettre en œuvre. Au lieu de vous fier aux préférences personnelles enregistrées dans Visual Studio ou aux paramètres de l'éditeur, vous pouvez désormais configurer un projet pour maintenir un style de codage cohérent pour tous les contributeurs.

Création du projet

Pour faire la démonstration du fichier EditorConfig, Tim crée un nouveau projet Blazor Server dans Visual Studio. Il la nomme BlazorDemoApp et utilise la configuration par défaut. Ce projet .NET simple sert de banc d'essai pour définir et appliquer les paramètres de EditorConfig.

Comme l'explique Tim, ce projet n'a pas besoin d'une logique ou d'une fonctionnalité complexe. Il s'agit simplement d'un exemple pratique pour travailler avec des règles de style de code.

Comprendre les préférences des projets et les styles de codage

Tim explique ici pourquoi la configuration au niveau du projet est importante. Dans Visual Studio, chaque utilisateur peut définir des préférences pour des éléments tels que :

• Utiliser des tabulations ou des espaces

• La taille du retrait (par exemple, 3 ou 4 espaces)

• Placement des accolades {} sur la même ligne ou sur de nouvelles lignes

• Le type de déclaration d'espace de noms (en bloc ou en fichier)

Ces préférences sont généralement stockées par utilisateur dans Visual Studio, et non par projet. Tim souligne que lorsqu'on travaille en équipe, les paramètres locaux de chacun peuvent être différents. La traduction doit rester professionnelle et préserver l'exactitude technique tout en expliquant les caractéristiques et les avantages de ces outils de développement, ce qui peut entraîner un formatage incohérent du code, des différences inutiles dans les systèmes de contrôle de version et une perte de temps pour aligner les préférences manuellement.

C'est là que le format de fichier EditorConfig est utile : il définit un ensemble partagé de propriétés EditorConfig que tous les éditeurs des développeurs peuvent respecter automatiquement.

Création et ouverture d'un fichier EditorConfig

Tim montre ensuite comment ajouter un nouveau fichier EditorConfig à la solution.

Il fait un clic droit sur la solution et sélectionne Ajouter → Nouvelle configuration de l'éditeur. Visual Studio peut générer une petite erreur lors du premier chargement du fichier, mais Tim explique qu'il s'agit d'une bizarrerie inoffensive - il suffit de fermer et de rouvrir le fichier.

Ce nouveau fichier est généralement nommé .editorconfig, et Visual Studio le reconnaît immédiatement comme un document de configuration. Il convient de noter que Visual Studio prend en charge ce fichier en mode natif, tout comme d'autres éditeurs de texte tels que Visual Studio Code et même Sublime Text, par le biais de modules d'extension d'éditeur de texte.

Tim précise que EditorConfig n'est pas un outil réservé à Microsoft. Il s'agit d'une norme sectorielle qui aide les différents éditeurs à comprendre et à appliquer les mêmes conventions de codage, garantissant ainsi une mise en forme cohérente dans plusieurs environnements.

Configuration de l'éditeurParamètres du fichier de configuration

Une fois le fichier EditorConfig ouvert, Tim explique qu'il reprend les paramètres par défaut de la configuration actuelle de Visual Studio. Toutefois, ces éléments peuvent être modifiés si nécessaire.

Il navigue jusqu'à la section Whitespace, où il montre comment définir les espaces blancs :

• Utiliser des tabulations au lieu d'espaces

• Largeur de la tabulation = 3

Voici des exemples de propriétés EditorConfig qui définissent le comportement de la mise en forme du code. Une fois enregistrée, cette configuration s'applique à l'ensemble de la solution, mais pas en dehors.

Tim note que ce fichier EditorConfig peut également être ajouté aux systèmes de contrôle de version (comme Git), afin de s'assurer que chaque développeur qui clone le référentiel hérite des mêmes règles. Cela permet de maintenir un formatage cohérent, quelle que soit la personne qui écrit le code.

Travailler avec les styles de code et les règles d'espace de noms

Tim se penche ensuite sur les paramètres de style de code, en particulier le style de déclaration d'espace de noms.

Par défaut, C# utilise des espaces de noms à portée de bloc, où l'espace de noms est défini à l'aide d'accolades. Tim crée une classe dans le dossier Data pour démontrer ce format.

Il modifie ensuite les paramètres du fichier EditorConfig afin d'utiliser les espaces de noms à l'échelle du fichier. Lorsqu'il ajoute une autre classe, Visual Studio applique automatiquement le style mis à jour - en affichant l'espace de noms avec un point-virgule ( ;) au lieu des accolades.

Ceci démontre comment les paramètres EditorConfig peuvent influencer les modèles de génération de code par défaut dans Visual Studio, en s'alignant automatiquement sur les conventions de projet définies.

Tim souligne également que la fonction de nettoyage du code peut être utilisée pour reformater les fichiers existants, en veillant à ce que tout le code respecte les dernières règles de l'EditorConfig.

Définition de la gravité et application des règles

Dans cette section, Tim se concentre sur la manière de contrôler l'application des règles à l'aide des niveaux de gravité dans le fichier EditorConfig.

Chaque règle peut avoir une valeur telle que none, suggestion, warning ou error. Tim définit la gravité de la règle d'espace de noms sur erreur, et Visual Studio signale immédiatement tout fichier ne correspondant pas au format préféré dans la fenêtre Liste d'erreurs.

Cela permet de s'assurer que les développeurs respectent les styles définis et d'éviter les déviations indésirables dans le fichier en cours ou dans l'ensemble du projet.

Bien que certaines incohérences ou certains bogues de Visual Studio puissent apparaître (par exemple, des invites de suggestion erronées), Tim note qu'ils s'amélioreront avec le temps. L'important est que les règles soient appliquées de manière cohérente, ce qui rend le code facilement lisible et uniforme.

Fichiers EditorConfig multiples et portée des répertoires

Tim poursuit en expliquant qu'il est possible d'avoir plusieurs fichiers EditorConfig dans une même solution.

Par exemple :

• Un fichier EditorConfig racine au niveau de la solution définit les paramètres généraux pour tous les projets.

• Un fichier EditorConfig imbriqué dans un sous-dossier comme /Data peut remplacer certaines propriétés (par exemple, les conventions de dénomination, la largeur de tabulation ou les sauts de ligne).

Chaque projet EditorConfig se comporte de manière hiérarchique, ce qui signifie que les fichiers des sous-répertoires héritent des répertoires parents, à moins qu'ils ne soient explicitement remplacés.

Si vous souhaitez définir la racine de votre configuration, vous pouvez définir la propriété root = true dans le fichier de premier niveau. Cela indique aux éditeurs d'arrêter de chercher d'autres fichiers EditorConfig dans les répertoires parents.

Cette structure permet aux développeurs de contrôler finement les règles de formatage au niveau du projet, tout en autorisant des cas particuliers où un formatage différent peut s'avérer judicieux.

Conclusion : Cohérence grâce à EditorConfig

Dans ses remarques finales, Tim encourage les développeurs à utiliser activement EditorConfig dans leurs projets .NET.

Il souligne que cette approche permet aux équipes de maintenir des règles de formatage, des conventions de dénomination et des styles de mise en page cohérents, sans avoir à modifier les paramètres personnels de l'éditeur. Chaque fichier ouvert suit automatiquement les styles définis dans le fichier .editorconfig du projet.

En intégrant ces fichiers EditorConfig dans les systèmes de contrôle de version, les équipes s'assurent que tout le monde - quel que soit l'éditeur ou l'environnement - respecte les mêmes règles de formatage du code.

Tim conclut sa vidéo en soulignant que le format de fichier EditorConfig est simple, flexible et largement pris en charge. Que vous utilisiez Visual Studio, Visual Studio Code ou un autre éditeur de texte, il fonctionne bien pour aider à maintenir des styles de codage cohérents et à garder votre projet propre, professionnel et lisible.