Comprendre les variables et les types de données en C#

Dynamique vs Var Différence

En C#, var est utilisé pour les variables locales implicitement typées où le type est déterminé au moment de la compilation, garantissant la sécurité des types et la prise en charge d'IntelliSense. En revanche, dynamic permet aux variables de contourner la vérification de type au moment de la compilation, le type étant résolu au moment de l'exécution, offrant plus de flexibilité mais avec le risque d'erreurs d'exécution et de performances réduites.

Tim Corey explique que var assure la sécurité des types avec la détermination des types au moment de la compilation car ce sont des variables statiques, tandis que dynamic offre une flexibilité avec la résolution des types à l'exécution, ce qui peut conduire à des erreurs d'exécution et à des problèmes de performance.

// Declaration of a dynamic variable that can change types at runtime
dynamic testDynamic;

// Declaration of a dynamic variable that can change types at runtime
dynamic testDynamic;

// This will result in a compile-time error due to lack of type inference
// var testVar;

// This will result in a compile-time error due to lack of type inference
// var testVar;

// var assignment with type inference from the initial value
var testVar = 2; // testVar is inferred to be of type int

// var assignment with type inference from the initial value
var testVar = 2; // testVar is inferred to be of type int

// Attempting to change the type from int to double causes an error
// testVar = 1.1; // Error: Cannot implicitly convert type 'double' to 'int'

// Attempting to change the type from int to double causes an error
// testVar = 1.1; // Error: Cannot implicitly convert type 'double' to 'int'

// Another example with dynamic typing
var testVar = 2.1; // Now testVar is a double

// Another example with dynamic typing
var testVar = 2.1; // Now testVar is a double

// Declaring a constant variable
const int MaxValue = 100;

// Declaring a constant variable
const int MaxValue = 100;

Conversion dynamique de type automatique

Tim souligne comment le mot-clé dynamic permet une gestion flexible des types en se comportant un peu comme object, mais avec des capacités supplémentaires. À 3:53, Tim démontre comment dynamic peut convertir de manière transparente entre différents types pendant l'exécution, démontrant sa capacité à gérer des calculs impliquant des entiers et des doubles sans conversion explicite, comme le montre son exemple de code :

// Demonstrating dynamic type conversion at runtime
dynamic testDynamic = 1;
testDynamic = testDynamic + 2.1;
Console.WriteLine(testDynamic); // Outputs 3.1 as it converts the integer to a double

// Demonstrating dynamic type conversion at runtime
dynamic testDynamic = 1;
testDynamic = testDynamic + 2.1;
Console.WriteLine(testDynamic); // Outputs 3.1 as it converts the integer to a double

Ici, Tim (4:39) illustre que testDynamic contient initialement une valeur entière mais la convertit sans effort en un double en y ajoutant 2,1, ce qui donne la sortie 3,1.

Malgré sa flexibilité, Tim met en garde contre la surutilisation de dynamic en raison des coûts de performance engendrés par les conversions de type fréquentes. Il souligne à 5:55 que dynamic doit être utilisé avec parcimonie dans le développement C# pour éviter une surcharge inutile du processeur et la perte de la vérification de type au moment de la compilation et du support IntelliSense, essentiels pour maintenir des bases de code robustes et sans erreur.

Inconvénients de Dynamic dans le développement

Tim Corey illustre comment dynamic peut entraîner des erreurs d'exécution et un comportement inattendu dans vos applications. Il commence par montrer comment déclarer une variable dynamique et lui assigner une chaîne initiale vide pour éviter une erreur immédiate. Il tente ensuite d'appeler une méthode inexistante sayHi sur la variable dynamique, ce qui ne provoque pas d'erreur de compilation mais entraîne une exception d'exécution, démontrant un inconvénient majeur de dynamic : l'absence de vérification au moment de la compilation.

// Demonstrating lack of compile-time checks with dynamic
dynamic testDynamic = "";
// testDynamic.sayHi(); // Runtime error: method does not exist

// Demonstrating lack of compile-time checks with dynamic
dynamic testDynamic = "";
// testDynamic.sayHi(); // Runtime error: method does not exist

En outre, à 8:38, Tim montre comment les variables dynamiques peuvent changer de type au moment de l'exécution, ce qui peut entraîner un comportement inattendu. Il assigne un objet Person à une variable dynamique, puis le réassigne à une chaîne de caractères, et montre comment cette flexibilité peut conduire à des erreurs logiques et rendre le débogage difficile.

// Demonstrating the potential errors with dynamic type reassignment
dynamic testDynamic = new Person();
testDynamic = "Hi";
Console.WriteLine(testDynamic); // Works fine, but not ideal for type safety

// Demonstrating the potential errors with dynamic type reassignment
dynamic testDynamic = new Person();
testDynamic = "Hi";
Console.WriteLine(testDynamic); // Works fine, but not ideal for type safety

Tim explique également que les variables dynamiques ne sont pas prises en charge par IntelliSense, ce qui peut entraîner des erreurs d'exécution dues à des fautes de frappe ou à des noms de méthode incorrects. Par exemple, à 14:05, il fait référence à une propriété nommée Email qui n'existe pas, ce qui montre que cette erreur passe inaperçue jusqu'à l'exécution. Le code se compile sans erreur, mais échoue à l'exécution lorsque les méthodes ou propriétés attendues sur l'objet Person sont introuvables dans la chaîne de caractères.

// Demonstrating a runtime error due to missing property
// testDynamic.Email = "Test@test.com"; // property not found until runtime

// Demonstrating a runtime error due to missing property
// testDynamic.Email = "Test@test.com"; // property not found until runtime

// Using var for strongly-typed assignments
var testVar = new Person();
testVar.FirstName = "Sue";
testVar.LastName = "Storm";

// The use of IntelliSense assists in reducing runtime errors
Console.WriteLine(testVar.SayHello()); // Ideally a method in Person class

// Using var for strongly-typed assignments
var testVar = new Person();
testVar.FirstName = "Sue";
testVar.LastName = "Storm";

// The use of IntelliSense assists in reducing runtime errors
Console.WriteLine(testVar.SayHello()); // Ideally a method in Person class

// Attempting to change type results in compile-time errors with var
// testVar = "Hi"; // Compile-time error

// Attempting to change type results in compile-time errors with var
// testVar = "Hi"; // Compile-time error

// Method returning a dynamic type
public dynamic GetMessage() {
    return "This is a test";
}

// Method returning a dynamic type
public dynamic GetMessage() {
    return "This is a test";
}

Pourquoi et quand utiliser Dynamic

Tim détaille les scénarios spécifiques où dynamic devient essentiel. Il explique que le C# est fondamentalement un langage fortement typé, ce qui signifie que chaque variable se voit attribuer un type définitif qui reste cohérent tout au long de son cycle de vie. 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, contrairement à des langages tels que JavaScript, où les variables peuvent changer de type de manière dynamique.

Tim, à 18:14, illustre le fait que si C# est conçu pour des variables à typage fort, il existe des situations, notamment lors de l'interaction avec des systèmes ou des langages externes tels que Python, Ruby ou des objets COM, où le typage dynamique peut être bénéfique. Il utilise l'exemple de l'intégration d'une API Python pour souligner le besoin pratique de dynamic. Dans ces cas, le fait de disposer d'un système de types flexible capable de s'adapter à divers types de données provenant de sources externes simplifie l'interaction.

Tim Corey à 18:44 souligne que si dynamic est utile pour les interactions entre langages, il n'est généralement pas recommandé pour le code C# pur en raison de la perte de la vérification des erreurs au moment de la compilation et de la prise en charge d'IntelliSense. Il prévient que la flexibilité de dynamic se fait au détriment des performances et de la sécurité des types, ce qui en fait un choix moins souhaitable pour la programmation C# régulière où les variables fortement typées devraient être préférées.

Pourquoi et quand utiliser le mot-clé Var

Tim aborde ensuite l'utilisation et la philosophie du mot-clé var en C#. Il note qu'il existe deux camps principaux en ce qui concerne l'utilisation de var : ceux qui préfèrent l'utiliser exclusivement et ceux qui privilégient les déclarations de type explicites.

Tim, à 19:43, explique que les partisans de var soutiennent qu'il encourage de meilleures conventions de nommage, rendant le code auto-documenté. Ils estiment que les noms de variables doivent être suffisamment descriptifs pour transmettre le type sans nécessiter de déclaration explicite.

De l'autre côté (20:46), ceux qui préfèrent les déclarations de type explicites affirment que le fait de voir le type réel directement dans le code permet de comprendre immédiatement le type d'une variable locale, sans qu'il soit nécessaire de survoler la variable pour voir son type. Par exemple :

// Explicit type declaration provides clarity
string firstName = "Tim";

// Explicit type declaration provides clarity
string firstName = "Tim";

Certains préfèrent cette méthode parce qu'elle lève toute ambiguïté sur le type de la variable.

Tim partage son approche équilibrée à 21:15, déclarant qu'il utilise généralement des types explicites pour les types de données courants comme string, int, double et decimal parce que cela rend le code plus clair et évite les problèmes potentiels, comme la confusion entre double et decimal. Par exemple:

// Explicit type ensures there's no ambiguity between float types
double myMoney = 1.1; // This is a double
decimal myMoney = 1.1M; // This is a decimal

// Explicit type ensures there's no ambiguity between float types
double myMoney = 1.1; // This is a double
decimal myMoney = 1.1M; // This is a decimal

Tim insiste sur le fait que la déclaration explicite du type garantit l'utilisation du bon type, en particulier lorsqu'il peut y avoir confusion entre des types similaires.

Cependant, Tim reconnaît également que var peut s'avérer particulièrement utile pour manipuler des types longs ou complexes. Il donne un exemple à 23:37 où la déclaration d'un List<List<Person>> peut être verbeuse :

// Declaring a complex type using var
var rounds = new List<List<Person>>();

// Declaring a complex type using var
var rounds = new List<List<Person>>();

Il démontre également son utilité dans les boucles foreach (23:55) :

// Utilizing var in loop for cleaner code
foreach (var round in rounds) {
    // Do something with each round
}

// Utilizing var in loop for cleaner code
foreach (var round in rounds) {
    // Do something with each round
}

Tim conclut en notant que si var peut réduire la verbosité, il est crucial de veiller à ce que les noms de variables soient clairs et descriptifs pour maintenir la lisibilité et éviter toute confusion.

En équilibrant l'utilisation de var avec des types explicites, les développeurs peuvent écrire un code clair, maintenable et efficace, en tirant parti des forces des deux approches selon le contexte.

Var en tant qu'objet anonyme

Tim aborde l'utilisation de var dans les situations où le type n'est pas explicitement connu ou lors de la manipulation de types anonymes. Il le démontre en créant à la volée un objet anonyme, sans type prédéfini. Voici le code qu'il utilise :

// Creating an anonymous object with var
var myItem = new { FirstName = "Tim", Email = "test@test.com" };

// Creating an anonymous object with var
var myItem = new { FirstName = "Tim", Email = "test@test.com" };

Tim, à 25:30, explique que puisque cet objet est anonyme et n'a pas de nom de type spécifique, la seule façon de déclarer des variables pour celui-ci est d'utiliser var. Cette approche permet la création et l'utilisation d'objets sans qu'il soit nécessaire de définir une classe formelle.

Pour illustrer la façon dont cela fonctionne en pratique, Tim écrit (25:52) :

// Outputting properties of an anonymous object
Console.WriteLine($"Hello {myItem.FirstName}: your email is {myItem.Email}");

// Outputting properties of an anonymous object
Console.WriteLine($"Hello {myItem.FirstName}: your email is {myItem.Email}");

Lorsqu'il exécute le code à 26:25, il produit un résultat :

Cela démontre que var peut gérer les propriétés d'un objet anonyme, et Visual Studio fournit une prise en charge IntelliSense pour ces propriétés, malgré le fait que l'objet soit anonyme.

Tim, à 26:54, précise qu'il préfère utiliser des types explicites pour les types simples et courants comme string, les entiers et les instances de classe parce que cela rend le code plus clair. Cependant, il utilise var dans les cas où le type est soit long, complexe, soit inconnu explicitement, comme avec les types anonymes ou les déclarations de types complexes.

Conclusion

Et voilà ! Une compréhension claire des variables et des types de données C#, ainsi que de l'utilisation stratégique des mots clés var et dynamic. En suivant l'approche équilibrée de Tim Corey, vous pouvez garantir la sécurité des types et la clarté de votre code avec le mot-clé var tout en tirant parti de la flexibilité du mot-clé dynamic pour des scénarios spécifiques comme l'interaction avec des systèmes externes.

Pour un aperçu plus détaillé, ne manquez pas de regarder la vidéo de Tim Corey sur "Dynamic vs Var in C#" et consultez sa YouTube Channel pour d'autres sujets d'apprentissage sur le C#.