14 façons de simplifier votre code C# - Aperçu des meilleures pratiques C# à partir de la vidéo de Tim Corey

1. L'utilisation statique pour un code plus propre

Tim commence par montrer comment l'accès statique peut simplifier les appels répétitifs. En déclarant :

using static System.Console;

using static System.Console;

vous n'avez plus besoin de préfixer chaque membre statique par Console...

Il ne s'agit pas seulement de supprimer des mots, mais de rendre l'accès statique clair. Tim souligne que si vous appelez un membre statique défini dans une classe fréquemment utilisée comme Console ou Math, cette abréviation améliore la lisibilité du code.

Toutefois, dans le cadre des bonnes pratiques de codage, il prévient que les développeurs doivent éviter les conflits - deux classes différentes peuvent avoir le même nom pour un membre statique. Il est essentiel d'être conscient des comportements inattendus potentiels.

2 Initialisation d'une liste avec

C# vous permet désormais d'initialiser des listes plus directement :

List<string> names = ["Tim", "Sue", "Bilbo"];

List<string> names = ["Tim", "Sue", "Bilbo"];

Tim explique qu'il ne s'agit pas de tout faire tenir en un seul énoncé, mais d'écrire un code plus facile à lire et d'optimiser les performances en réduisant le nombre de cérémonies.

Au lieu d'analyser le texte passe-partout "new List of String", le lecteur voit exactement ce qui compte : les noms descriptifs de la collection. Tim note également que cela fonctionne pour les tableaux et même les dictionnaires, en s'alignant sur les conventions de codage qui donnent la priorité à la clarté.

3. nouveau type de cible

Autre gain de temps : la nouvelle typographie ciblée. Au lieu de :

List<int> numbers = new List<int>();

List<int> numbers = new List<int>();

vous pouvez écrire :

List<int> numbers = new();

List<int> numbers = new();

Tim souligne qu'il est inutile de répéter le nom de la classe, qui figure déjà sur le côté gauche. Il s'agit de respecter les bonnes pratiques de codage en supprimant les redondances tout en facilitant l'analyse de votre base de code.

4. var et les types anonymes

Tim s'attaque à var, une fonctionnalité qui suscite le débat dans les cercles des pratiques de codage. Certains ne l'apprécient pas parce qu'il cache les noms et les types de variables, mais Tim précise que sa véritable puissance réside dans les types anonymes.

Lorsque vous travaillez avec des sources de données (comme SQL via Dapper), Tim montre comment var vous permet de créer des objets à la volée :

var parameters = new { FirstName = "Tim", LastName = "Corey" };

var parameters = new { FirstName = "Tim", LastName = "Corey" };

C'est parfait pour les requêtes d'écriture ou les objets uniques - il n'est pas nécessaire de créer une classe de base uniquement pour les paramètres. Comme le dit Tim, cela évite de polluer votre base de code avec des types inutiles, tout en fournissant des messages d'erreur significatifs en cas de problème.

5. Espaces de noms à l'échelle du fichier

Tim passe aux espaces de noms à l'échelle du fichier, en montrant comment cela fonctionne :

namespace ProjectName
{
    // indented code
}

namespace ProjectName
{
    // indented code
}

devient ceci :

namespace ProjectName;

namespace ProjectName;

Cette petite modification élimine les indentations inutiles et respecte les conventions de dénomination du C#, comme le casing Pascal pour les membres publics. Tim explique que la plupart des fichiers ne contiennent qu'un seul espace de noms, ce qui améliore la lisibilité du code et permet d'aligner les sections logiques.

6. Enregistrements pour les structures de données à une ligne

L'utilisation d'enregistrements vous permet de définir des objets de données en une seule déclaration :

public record EmployeeRecord(int Id, string Name);

public record EmployeeRecord(int Id, string Name);

Tim note que cela génère un type complet - propriétés, immuabilité et ToString() - avec un minimum d'effort. Il est clair que les scénarios de classes dérivées nécessitent toujours des classes, mais lorsque votre objet est en lecture seule, les enregistrements suivent le principe de la responsabilité unique en faisant bien un seul travail.

7 Correspondance de motifs

Tim montre comment le filtrage par motif permet de gérer les exceptions et d'effectuer des comparaisons en toute sécurité. Au lieu d'écrire des vérifications de type verbeuses, vous pouvez les combiner :

if (emp is EmployeeRecord e)
{
    e.Id = 1;
}

if (emp is EmployeeRecord e)
{
    e.Id = 1;
}

Cette ligne unique permet de vérifier et de mouler. Tim explique que cela correspond aux bonnes pratiques de codage, qui consistent à éviter les noms de variables d'une seule lettre, comme x ou y, et à leur préférer des noms descriptifs, comme e. Des noms de méthodes et de variables clairs facilitent la maintenance du code pour les autres développeurs.

8 Interpolation de chaînes de caractères

Pour construire des chaînes lisibles, Tim démontre l'interpolation de chaînes :

$"The employee with ID {e.Id} is {e.Name}"

$"The employee with ID {e.Id} is {e.Name}"

Il souligne que cela facilite la compréhension des messages d'erreur et des commentaires d'écriture. Au lieu d'une concaténation enchevêtrée, vous pouvez littéralement écrire du code qui se lit comme de l'anglais, ce qui améliore la qualité du code et simplifie les futurs tests unitaires qui vérifient la sortie.

9. nameof() pour un refactoring sûr

Tim montre comment nameof() vous protège lorsque vous remaniez du code. Les noms de variables codés en dur dans des chaînes de caractères peuvent entraîner un comportement inattendu s'ils sont renommés. Mais en écrivant :

nameof(emp)

nameof(emp)

le compilateur met à jour automatiquement chaque utilisation. Il s'agit de l'une des meilleures pratiques qui permet à votre base de code de rester saine lorsque vous écrivez un code propre et que vous le réorganisez.

10. Tuples pour les valeurs de retour multiples

Au lieu de créer une classe de base pour renvoyer deux valeurs, Tim utilise des tuples :

(string FirstName, string LastName) SplitName(string fullName)

(string FirstName, string LastName) SplitName(string fullName)

Cela permet d'éviter les dépendances externes inutiles et d'adhérer au principe de responsabilité unique - la méthode ne fait que scinder un nom, rien de plus. Comme le dit Tim, la pratique permet d'améliorer le code en évitant la sur-ingénierie.

11. Déconstruction

En s'appuyant sur les tuples, Tim montre comment déconstruire les résultats en variables locales :

var (firstName, lastName) = SplitName("Tim Corey");

var (firstName, lastName) = SplitName("Tim Corey");

Les noms de variables doivent être descriptifs et la syntaxe des tuple cryptique doit être évitée par la suite. Tim aborde même la question de l'élimination des valeurs inutilisées (à l'aide de _), ce qui indique l'intention - aucun nom de variable à une seule lettre n'est laissé sans explication.

12. Rejet des valeurs inutiles

Si vous n'avez pas besoin de toutes les parties d'un tuple, Tim recommande les discards :

var (firstName, _) = SplitName("Tim Corey");

var (firstName, _) = SplitName("Tim Corey");

Cela montre aux autres développeurs que vous ignorez intentionnellement une valeur, ce qui est bon pour tester des cadres ou des tests unitaires où tous les résultats n'ont pas d'importance.

13. utiliser des déclarations sans blocs

Tim aborde la gestion des ressources et le traitement des erreurs. Auparavant, vous deviez écrire :

using (var connection = new SqlConnection(connString))
{
    // work
}

using (var connection = new SqlConnection(connString))
{
    // work
}

Vous pouvez désormais utiliser :

using var connection = new SqlConnection(connString);

using var connection = new SqlConnection(connString);

La traduction doit être conforme aux principes SOLID, notamment le principe de responsabilité unique et le principe d'inversion des dépendances. Tim note que cette syntaxe fonctionne bien pour les dépendances externes telles que les bases de données, garantissant que la plupart des traitements d'exception sont plus propres et que les connexions sont toujours fermées, évitant ainsi les problèmes de performance ou même les scénarios d'injection SQL lorsque les connexions ne sont pas éliminées.

14. Déclarations de variables inline out

Enfin, Tim couvre les déclarations de variables inline out pour des choses comme l'analyse syntaxique :

if (int.TryParse(numberText, out int numberValue))

if (int.TryParse(numberText, out int numberValue))

Ici, vous créez la variable locale sur la même ligne. Les conventions de codage restent ainsi strictes et les noms de méthodes descriptifs. En gardant le code correctement groupé, vous réduisez les comportements inattendus et rendez plus sûrs les futurs efforts de refonte du code.

Conclusion

Tim conclut sa vidéo en rappelant aux spectateurs que ces simplifications n'ont rien à voir avec la rédaction d'une seule ligne cryptique, mais qu'il s'agit de bonnes pratiques de codage. Des fonctionnalités telles que l'utilisation de statiques, d'enregistrements, de filtrage, de tuples et de rejets vous permettent d'écrire du C# propre et moderne.

Il encourage les développeurs à réfléchir aux conventions de dénomination, à la gestion des erreurs et aux noms significatifs lorsqu'ils adoptent ces fonctionnalités. "Le code est destiné à être lu par des humains", explique Tim, et lorsque vous écrivez du code facile à comprendre, vous améliorez votre vie et celle des autres développeurs.

En résumé : adoptez ces meilleures pratiques C#, suivez les principes SOLID tels que le principe de responsabilité unique, le principe de séparation des interfaces et le principe d'inversion des dépendances, et votre code ne se contentera pas de compiler - il améliorera les performances, réduira les comportements inattendus et permettra à votre équipe de coder en toute sérénité.