Initialisation des propriétés automatiques en C# : TOP 5 des erreurs et masterclass

Introduction : pourquoi la question sur les propriétés automatiques a-t-elle rassemblé des milliers de vues ?

Si vous avez déjà écrit en C#, vous avez sûrement rencontré une question simple mais importante : "Comment définir correctement la valeur initiale d'une propriété automatique ?". Cette question sur Stack Overflow a rassemblé des dizaines de milliers de vues, et ce n'est pas pour rien. La simplicité apparente cache de nombreux pièges.

Imaginez : vous créez une classe User, et vous souhaitez que la propriété Name ne soit pas null par défaut, mais une chaîne vide. Que pourrait-il mal se passer, semble-t-il ? Mais en pratique, les développeurs commettent des erreurs typiques d'initialisation des propriétés C#, qui conduisent à des NullReferenceException ou à un comportement non évident.

Dans cet article, nous analyserons le TOP 5 des erreurs et montrerons comment les éviter. Vous découvrirez les approches modernes — de C# 6 à C# 12 — et comprendrez quelle méthode choisir pour votre projet.

Erreur n°1 : Ignorer l'initialisation des propriétés automatiques

L'erreur la plus courante est de ne pas définir de valeur initiale pour les types référence. De nombreux débutants écrivent :

public class User\n{\n    public string Name { get; set; } // null par défaut\n    public List<string> Roles { get; set; } // null\n}

En C#, les propriétés automatiques pour les types référence sont égales à null par défaut. Cela entraîne des problèmes de NullReferenceException lorsque vous oubliez d'assigner une valeur avant utilisation.

Comment corriger ?

Définissez toujours explicitement un initialiseur de propriété automatique C#. La méthode la plus simple consiste à utiliser la syntaxe C# 6 :

public class User\n{\n    public string Name { get; set; } = string.Empty;\n    public List<string> Roles { get; set; } = new List<string>();\n}

\n

Conseil : Utilisez string.Empty au lieu de guillemets vides — cela améliore la lisibilité et respecte les bonnes pratiques C#.

\n

Erreur n°2 : Initialisation dans le constructeur sans tenir compte de la chaîne d'appels

Une autre erreur fréquente est de définir la valeur par défaut C# uniquement dans le constructeur, tout en ignorant les initialiseurs de propriétés. Cela peut entraîner une confusion, surtout en cas d'héritage.

public class BaseClass\n{\n    public int Value { get; set; }\n\n    public BaseClass()\n    {\n        Value = 10;\n    }\n}\n\npublic class DerivedClass : BaseClass\n{\n    public DerivedClass()\n    {\n        // Value est déjà = 10, mais nous pouvons la réécrire\n    }\n}

Problème : si vous ajoutez un initialiseur à la propriété Value et conservez l'assignation dans le constructeur, l'ordre d'exécution peut vous surprendre. Les initialiseurs s'exécutent avant le corps du constructeur de la classe de base, mais après l'appel du constructeur de la classe dérivée.

Comment l'éviter ?

Choisissez une seule méthode : soit l'initialiseur, soit le constructeur. Il est préférable de privilégier les initialiseurs de propriétés automatiques C#, car ils sont plus prévisibles et concis.

public class BaseClass\n{\n    public int Value { get; set; } = 10; // Source unique de vérité\n}

Erreur n°3 : Utilisation de champs readonly au lieu de propriétés automatiques

Certains développeurs, en essayant de définir une valeur initiale, abandonnent les propriétés automatiques et utilisent des champs publics :

public class Config\n{\n    public readonly int MaxRetries = 3; // Erreur : violation de l'encapsulation\n}

C'est une mauvaise pratique. Les champs violent l'encapsulation — vous ne pourrez pas ajouter de logique dans le getter/setter sans modifier l'API. De plus, cela créera des problèmes lors de la sérialisation ou de l'utilisation dans WPF/Blazor.

Approche correcte

Utilisez des propriétés automatiques avec initialisation ou des propriétés init-only C# 9 :<