C # - StyleCop - SA1121: UseBuiltInTypeAlias - Règles de lisibilité

Question

Pas trouvé dans StyleCop Manuel d'Aide, sur ce qui est et Google si elle est ici ;)

Au cours de StyleCop utilisation j'ai un message d'avertissement:

SA1121 - UseBuiltInTypeAlias - La Lisibilité Des Règles

Le code utilise l'une de base de C# types, mais ne pas utiliser le haut- alias pour le type.

Plutôt que d'utiliser le nom du type ou de la complet, tapez le nom, l' construit-dans des alias pour ces types doit toujours être utilisé: bool, byte, char, virgule, double, short, int, longtemps, l'objet, sbyte, float, string, ushort, uint, ulong.

donc, String.Empty est faux (dépendent des règles ci-dessus) et string.Empty est bon.

Pourquoi à l'aide intégrée dans les alias est le meilleur? Peut - String. Int32, Int64 (etc.) compliquer quelque chose dans le code spécial sur les scénarios?

Answer 1

Juste pour clarifier: pas tout le monde est d'accord avec les auteurs de StyleCop. Win32 et .NET le gourou de Jeffrey Richter écrit dans son excellent livre CLR via C#:

La spécification du langage C# unis", Comme une question de style, l'utilisation du mot-clé est favorisée par rapport à l'utilisation de l'ensemble du système de nom de type." Je suis en désaccord avec la spécification du langage; je préfère pour utiliser le FCL type de noms et d'éviter complètement le type primitif des noms. En fait, je souhaite que les compilateurs n'offrent même pas le type primitif des noms et forcé les développeurs à utiliser le FCL les noms de type de la place. Voici mes raisons:

• J'ai vu un certain nombre de développeurs confuse, ne sachant pas si l'utilisation de la chaîne ou Chaîne dans leur code. Parce qu'en C# chaîne de caractères (un mot-clé) cartes exactement à Système.Chaîne de caractères (une FCL type), il n'y a pas de différence et peuvent être utilisés. De même, J'ai entendu dire que certains développeurs disent que int représente un entier de 32 bits lors de l'application est en cours d'exécution sur un 32-bit OS et qu'il représente un entier de 64 bits lors de l'application est en cours d'exécution sur un système d'exploitation 64 bits. Cette déclaration est absolument faux: en C#, un int toujours des cartes pour le Système.Int32, et par conséquent, il représente un entier de 32 bits quel que soit le système d'exploitation le le code est en cours d'exécution sur. Si les programmeurs utilisent Int32 dans leur code, puis ce potentiel la confusion est également éliminé.

• En C#, longue de cartes à Système.Int64, mais dans un autre langage de programmation, long pourrait correspondre à une Int16 ou Int32. En fait, C++/CLI ne traiter long comme un Int32. Quelqu'un de lire le code source dans un langage facilement mal interpréter le code de la intention si il ou elle ont été utilisés pour la programmation dans un autre langage de programmation. En fait, la plupart des langues n'a même pas de traiter long comme un mot-clé et de ne pas compiler du code qui l'utilise.

• Le FCL a beaucoup de méthodes qui ont des noms de type dans le cadre de leurs noms de méthode. Pour exemple, le BinaryReader offre des méthodes telles que ReadBoolean, ReadInt32, ReadSingle, et ainsi de suite, et le Système.Convertir offre des méthodes telles que ToBoolean, ToInt32, ToSingle, et ainsi de suite. Même si c'est légal d'écrire ce qui suit code, la ligne avec flotteur se sent très naturelle pour moi, et il n'est pas évident que la ligne est correct:

  BinaryReader br = new BinaryReader(...);
  float val = br.ReadSingle(); // OK, but feels unnatural
  Single val = br.ReadSingle(); // OK and feels good
  

• Beaucoup de programmeurs qui utilisent C# exclusivement tendance à oublier que d'autres émissions langues peuvent être utilisées à l'encontre de la CLR, et à cause de cela, C#-ismes de loup dans la classe code de la bibliothèque. Par exemple, Microsoft FCL est presque entièrement écrit en C# et les développeurs sur le FCL de l'équipe ont mis en place des méthodes dans la bibliothèque comme Tableau's GetLongLength, qui retourne un Int64 valeur qui est un long en C# mais pas dans d'autres langages (comme C++/CLI). Un autre exemple est le Système.Linq.Énumérable's LongCount méthode.

Answer 2

Il ne serait vraiment compliquer le code si vous aviez votre propre String, Int32 etc les types qui pourraient être utilisées à la place de System.* - et s'il vous plaît ne le faites pas!

Finalement, c'est une question de préférence personnelle. J'utilise l'alias de partout, mais je sais que certaines personnes (par exemple, Jeffrey Richter) conseiller de ne jamais les utiliser. C'est probablement une bonne idée d'être cohérent, c'est tout. Si vous n'aimez pas que StyleCop de la règle, de le désactiver.

Notez que les noms de méthodes, etc ... doivent utiliser le cadre nom, plutôt que de l'alias, de manière à être indépendant de la langue. Ce n'est pas si important pour le secteur privé / les membres internes, mais vous pourriez aussi bien avoir les mêmes règles pour les méthodes privées comme celles du public.

Answer 3

Parce que l'alias intégré est un moyen plus naturel d'exprimer le concept dans cette langue.

Certaines cultures parlent de football, d’autres de football. Lequel est le plus approprié dépend du contexte.

Answer 4

Cette règle StyleCop suppose que l’utilisation d’alias crée moins de confusion pour «l’utilisateur de langue moyenne» supposé-exister. Ce qui connaît, par exemple, le type 'long', mais effrayant en quelque sorte le type 'System.Int64' et se perd, puis le voit. Personnellement, je pense qu’il est important d’être cohérent dans votre style de code, il est impossible de satisfaire tout le monde .

Answer 5

Moins déroutant? Cela me semble très pénible pour un type de données de base, qui n'est traditionnellement qu'une valeur, d'inclure des fonctions statiques. Je comprends utiliser l’équivalent de type de données de base si vous ne stockez qu’une valeur, mais pour accéder aux membres de la classe, il semble très difficile de placer un. (Point) après le nom du type de base.