Une simplification qui fera jaser car elle tend à entretenir la confusion entre les différentes méthodes de différentes classes… Et vous que pensez-vous de ces nouveaux espaces de noms statiques ?
.NET le pays des espaces de noms !
Même si la notion d’espaces de noms n’est pas une invention de .NET ce Framework a exploité à merveille le principe en mettant de l’ordre dans les centaines d’API Windows disponibles. Pour simplifier l’écriture .NET autorise l’utilisation de déclarations “using” en début de code pour lister les espaces de noms utilisés. Ce qui permet ensuite d’utiliser les classes de ces derniers sans avoir besoin de les préfixer. L’écriture s’en trouve allégée grandement. Et la lecture aussi ce qui est finalement le véritablement but.
Les classes statiques comme espaces de noms
La nouveauté de C# 6 est de permettre par une syntaxe similaire d’assimiler une classe statique à un espace de nom, ce qui conceptuellement ne pose aucun problème, le nom d’une classe dans un espace de noms n’est jamais qu’une feuille terminale dans l’arborescence des espaces de noms dont elle est issue.
Avec “using” on s’arrêtait au “namespace” qui précède la déclaration de la classe. Mais il faut avouer que les classes statiques obligeaient ensuite à des répétitions très semblables à ce qu’aurait été le code sans l’astuce des “using”.
Ainsi on pouvait écrire jusqu’ici un code de ce type :
Le mieux qu’on pouvait faire pour atteindre la classe statique Console c’était de déclarer la chaîne d’espaces de noms qui la précédait. Dans le cas de Console cela se limitait à “using System;” Pour d’autres classes la chaîne peut devenir très longue.
Malgré cette simplification à chaque utilisation d’une méthode de Console il fallait préfixer l’appel du nom de la classe statique comme le montre l’exemple ci-dessus.
Quand on doit écrire de nombreux appels à des méthodes d’une classe statique le code devient vite répétitif, ce qui endort la vigilance lors de sa lecture.
L’ajout de C# 6 consiste donc à considérer que les classes statiques, plutôt leur nom, font partie de la chaîne qui peut être déclarée par “using”.
Le code de l’exemple devient ainsi :
On remarque la déclaration “using static System.Console;” ce qui permet l’utilisation de “Write” comme s’il s’agissait d’une méthode de la classe en cours (Program).
On peut bien entendu utiliser toute classe statique de cette façon. Par exemple en déclarant un “using static System.Environment” on peut accéder directement à “NewLine”. Le code :
Console.Write(Environment.Newline);
devient alors
Write(NewLine);
La lecture devient bien plus simple.
Enfer ou paradis ?
Comme toutes les simplifications syntaxiques il y a un risque de confusion. On voit encore des gens qui n’utilisent pas “var” et qui préfixent de toute la chaîne de namespaces la moindre déclaration pour s’assurer que leur intention est comprise et qu’aucun mélange ne risque de venir prêter à confusion.
Forcément en poussant le “using” jusqu’aux noms des classes statiques, en donnant l’impression qu’une méthode appartient à une classe dans laquelle elle n’est en réalité pas déclarée, il y a comme une confusion possible.
Mais elle est levée d’une part par la connaissance du Framework (mais ce n’est pas un argument suffisant je suis d’accord) et par Visual Studio qui permet en survolant un code de savoir exactement d’où provient une classe (mais cela reste caché à la simple lecture du texte).
Il n’en reste pas moins vrai que certains considèrerons cette façon d’écrire trop peu respectueuse des intentions et donc nuisant à la lisibilité du code (ce qui est un comble mais qui se justifie) et d’autres qui y verront une façon de justement rendre leur code plus lisible…
Conclusion
En partant du même constat on peut arriver à deux positions radicalement opposées… Alors lisible ou pas lisible les espaces de noms statiques ?
Je ne trancherai pas, à vous de dire ce que vous en pensez !
Stay Tuned !