Existe-t-il des inconvénients aux qualificatifs redondants? Tout avantage?

Question

Par exemple, référence à quelque chose comme System.Data.Datagrid par opposition à simplement Datagrid. Veuillez fournir des exemples et des explications. Merci.

Answer 1

L'avantage est que vous n'avez pas besoin d'ajouter une importation pour tout ce que vous utilisez, surtout si c'est la seule chose que vous utilisez depuis un espace de noms particulier, cela évite également les collisions.

L’inconvénient, bien sûr, est que le code monte en flèche et devient de plus en plus difficile à lire au fur et à mesure que vous utilisez des qualificateurs spécifiques.

Personnellement, j'ai tendance à utiliser les imports pour la plupart des choses, sauf si je suis sûr que je n'utiliserai qu'une ou deux fois quelque chose provenant d'un espace de noms particulier. Cela n'aura donc aucune incidence sur la lisibilité de mon code.

Answer 2

Vous êtes très explicite sur le type que vous référencez, et c'est un avantage. Bien que, dans le même processus, vous donniez la clarté du code, ce qui est clairement un inconvénient dans mon cas, car je veux que le code soit lisible et compréhensible. Je choisis la version courte à moins que je ne rencontre un conflit dans différents espaces de noms, problème qui ne peut être résolu que par le référencement explicite de classes. Sauf si je lui attribue un alias avec le mot-clé

using Datagrid = System.Data.Datagrid;

Answer 3

En fait, le chemin complet est global :: System.Data.DataGrid . L'utilisation d'un chemin plus qualifié évite d'avoir à utiliser d'autres instructions using, en particulier si l'introduction d'une autre utilisation causera des problèmes de résolution de type. Des identificateurs plus qualifiés existent pour vous permettre d'être explicite lorsque vous avez besoin d'être explicite, mais si l'espace de nom de la classe est vide, la version DataGrid est plus claire pour beaucoup.

Answer 4

J'utilise généralement le formulaire le plus court disponible afin de garder le code aussi propre et lisible que possible. Après tout, c’est à cela que servent les directives d’utilisation, et les info-bulles de l’éditeur VS fournissent des détails instantanés sur la provenance d’un type.

J'ai également tendance à utiliser une balise d'espace de noms pour les RCW dans une couche COM interop, afin d'appeler ces variables explicitement dans le code (elles peuvent nécessiter une attention particulière sur le cycle de vie et la collecte), par exemple

.

using _Interop = Some.Interop.Namespace;

Answer 5

En termes de performance, il n’ya pas de potentiel positif / négatif. Tout est résolu au moment de la compilation et le MSIL généré est identique, que vous utilisiez des noms entièrement qualifiés ou non.

La raison pour laquelle son utilisation est répandue dans le monde .NET est due à un code généré automatiquement, tel que le balisage de concepteur. Dans ce cas, il serait préférable de qualifier complètement les noms tels que les noms de classe en raison des conflits possibles avec d’autres classes que vous pourriez avoir dans votre code.

Si vous disposez d'un outil tel que ReSharper, il vous dira quelles références entièrement qualifiées vous êtes inutiles (par exemple en les grisant) afin que vous puissiez les découper. Si vous copiez souvent du code sur vos différentes bases de code, il serait indispensable de les qualifier complètement. (Là encore, pourquoi voudriez-vous faire du copier-coller tout le temps? C'est une mauvaise forme de réutilisation de code!)

Answer 6

Je ne pense pas qu'il y ait vraiment un inconvénient, juste la lisibilité par rapport au temps réel passé à coder. En général, si vous n'avez pas d'espaces de noms avec un objet ambigu, je ne pense pas que ce soit vraiment nécessaire. Une autre chose à considérer est le niveau d'utilisation. Si vous utilisez une méthode qui utilise la réflexion et que vous saisissez bien System.Reflection 10 fois, alors ce n'est pas grave, mais si vous envisagez d'utiliser un espace de noms, vous pouvez recommander l'inclusion.

Answer 7

En fonction de votre situation, des qualificatifs supplémentaires généreront un avertissement (si c'est ce que vous entendez par redondant). Si vous traitez ensuite les avertissements comme des erreurs, c'est un inconvénient assez sérieux.

Je l'ai rencontré par exemple avec GCC.

struct A {
    int A::b; // warning!
}