C# en équipe : code style et conventions qui sauveront votre projet

Pourquoi le code style n'est pas une question de « je vois les choses comme ça »

Avez-vous déjà ouvert du code C# écrit par quelqu'un d'autre et vous êtes-vous senti comme un archéologue fouillant les ruines d'un temple ancien ? public int a;, var x = GetSmth() sans contexte et des méthodes de 400 lignes. Si oui, vous savez à quel point une équipe sans code style unifié peut avoir mal à la tête.

Travailler en équipe, ce n'est pas seulement Git et la revue de code. C'est aussi le fait que votre code est lu par d'autres personnes. Et si vous écrivez pour vous-même, le code style pour C# est une bureaucratie ennuyeuse. Mais si vous écrivez pour l'équipe, c'est un soulagement pour les nerfs, le temps et la production.

Dans cet article, nous allons voir quelles conventions C# fonctionnent réellement en 2024, comment les mettre en œuvre sans douleur et pourquoi EditorConfig est votre meilleur ami. C'est parti.

Règles de base : sur quoi se mettre d'accord en premier

1. Nommage (naming conventions)

En C#, il existe des normes strictes, mais les équipes les enfreignent souvent. Voici le minimum vital accepté par 90 % des équipes .NET :

\n
• PascalCase — pour les classes, méthodes, propriétés, champs publics : public class UserService, public string GetUserName().
\n
• camelCase — pour les variables locales, paramètres de méthodes, champs privés (souvent avec le préfixe _) : private int _userId;, var userName = "Alex";.
\n
• Évitez la notation hongroise — strName, intCount — c'est dépassé. Le type de la variable doit être évident d'après le contexte.
\n
• N'abrégez pas sans nécessité — GetUsrInf() est pire que GetUserInformation(). Exception : les abréviations courantes (IO, UI, DTO).
\n

// Mauvais\npublic class user_service\n{\n    public int id;\n    public string nm;\n    private string _data;\n    public string GetData() => _data;\n}\n\n// Bon\npublic class UserService\n{\n    public int Id { get; }\n    public string Name { get; }\n    private readonly string _userData;\n\n    public string GetUserData() => _userData;\n}

2. Formatage : espaces, accolades, lignes vides

Les débats sur l'opportunité de mettre un espace avant les deux-points dans catch (Exception e) sont infinis. Utilisez donc des outils automatiques. Mais des accords de base sont tout de même nécessaires :

\n
• Indentation — 4 espaces (la tabulation est rarement utilisée en C#, mais si l'équipe a choisi les tabulations, c'est acceptable).
\n
• Accolades — toujours sur une nouvelle ligne (style Allman). C'est la norme pour C#.
\n
• Une ligne vide entre les méthodes. Deux entre les classes.
\n

// Mauvais (accolades sur la même ligne — c'est Java, pas C#)\npublic void Process() {\n    var result = Calculate();\n    return result;\n}\n\n// Bon (style Allman)\npublic void Process()\n{\n    var result = Calculate();\n    return result;\n}

Conventions avancées : sur quoi on bute le plus souvent

3. Utilisation de var

Un des débats éternels. La règle est simple : utilisez var lorsque le type est évident d'après la partie droite. Sinon, écrivez-le explicitement.

// On peut utiliser var\nvar users = GetUsers(); // le type est évident\nvar dictionary = new Dictionary<string, int>(); // déclaration longue\n\n// Mieux vaut être explicite\nUser user = GetUserById(id); // pas évident que User est retourné\nDictionary<string, int> result = ParseData(); // pas évident non plus

Si votre équipe n'aime pas var — mettez-vous simplement d'accord. L'essentiel est l'uniformité.

4. Travail avec LINQ

LINQ est un outil puissant mais perfide. Une erreur fréquente est d'avoir des chaînes de 10 méthodes qui se lisent comme une incantation. Mettez-vous d'accord :

\n
• Divisez les longues expressions LINQ sur plusieurs lignes.
\n
• N'abusez pas de .Select() là où une simple boucle suffit.
\n