Pourquoi serait-var est une mauvaise chose?

Question

J'ai été en discutant avec mes collègues de l'autre jour et entendu que leur norme de codage explicitement interdit l'utilisation de l' var mot-clé en C#. Ils n'avaient aucune idée de pourquoi il en était ainsi et j'ai toujours trouvé que la déclaration implicite à être incroyablement utile lors du codage. Je n'ai jamais eu de problèmes à trouver ce type de la variable a (vous passez la souris sur la variable VS, et vous obtiendrez le type de cette façon).

Personne ne sait pourquoi ce serait une mauvaise idée d'utiliser le mot-clé var en C#?

Answer 1

Les auteurs de l' .Net Cadre des lignes Directrices de Conception (livre génial) qui est sorti en novembre 2008 recommandons de considérer l'aide d' var lorsque le Type est évident et sans ambiguïté.

D'autre part, si vous utilisez var entraînerait une ambiguïté lors de la lecture du code, comme Anton Gogolev souligné, alors il est préférable de ne pas l'utiliser.

dans le livre (Annexe A), ils ont en fait de donner cet exemple:

var names = new List<string>(); // good usage of var

string source = GetSource();
var tokens = source.Split(' '); // ok; most developers know String.Split

var id = GetId(); // Probably not good; it's not clear what the type of id is

Il est possible que, pour s'assurer que la lisibilité n'est pas soumis aux caprices des humbles de développeurs, votre organisation a décidé que vous n'étiez pas digne d' var et de l'interdire.
C'est une honte, si, c'est comme avoir un bel outil à votre disposition, mais de le garder enfermé dans un cabinet de verre.

Dans la plupart des cas, l'utilisation d' var pour les types simples, permet en fait de la lisibilité et nous ne devons pas oublier qu'il ya aussi pas de perte de performance pour l'utilisation de var.

Answer 2

var q = GetQValue();

est en effet une mauvaise chose. Cependant,

var persistenceManager = ServiceLocator.Resolve<IPersistenceManager>();

est parfaitement bien pour moi.

La ligne de fond est: descriptifs d'identifiants et vous obtiendrez le long de l'amende juste.

Au passage: je me demande comment font-ils traiter avec des types anonymes lorsqu'il n'est pas autorisé à utiliser var mot-clé. Ou ils ne les utilisent pas tout à fait?

Answer 3

Dans la plupart des cas, lorsqu'utilise judicieusement (c'est à dire un type simple d'initialiseur où le type et la valeur sont les mêmes), il est bien.

Il y a certains moments où il est difficile de savoir que vous avez cassé des choses en changeant elle - surtout quand la initialisée type et l' (d'origine) type de variable ne sont pas les mêmes, parce que:

• la variable a été à l'origine de la classe de base
• la variable a été à l'origine d'une interface
• la variable a été à l'origine d'un autre type avec un opérateur de conversion implicite

Dans ces cas, vous pouvez avoir des ennuis avec n'importe quel type de résolution - par exemple:

• les méthodes qui sont différentes des surcharges pour les deux types de compétition
• les méthodes d'extension sont définis différemment pour les deux types de compétition
• les membres qui ont été re-déclaré (caché) sur l'un des types
• l'inférence de type générique fonctionnera différemment
• l'opérateur de résolution de travailler différemment

Dans de tels cas, vous changez le sens du code, et d'exécuter quelque chose de différent. C'est alors une mauvaise chose.

Exemples:

La conversion implicite:

static void Main() {
    long x = 17;
    Foo(x);
    var y = 17;
    Foo(y); // boom
}
static void Foo(long value)
{ Console.WriteLine(value); }
static void Foo(int value) {
throw new NotImplementedException(); }

Méthode de masquage:

static void Main() {
    Foo x = new Bar();
    x.Go();
    var y = new Bar();
    y.Go(); // boom
}
class Foo {
    public void Go() { Console.WriteLine("Hi"); }
}
class Bar : Foo {
    public new void Go() { throw new NotImplementedException(); }
}

etc

Answer 4

C'est sûrement une erreur. C'est parce que certains folk ne se rendent pas compte qu'il est en fait fortement typés, et pas du tout comme un var en VB.

Pas toutes les normes de codage de sens, une fois, j'ai travaillé pour une entreprise qui voulait préfixe tous les noms de classe avec le nom de la société. Il y eut un énorme retravailler lorsque la société a changé son nom.

Answer 5

J'ai écrit un article de blog sur ce sujet il y a quelques mois. Pour moi, je l'utilise tous les, si possible, et plus précisément la conception de mon Api autour de l'inférence de type. Les raisons à la base j'utilise l'inférence de type sont

1. Il ne permet pas de réduire de sécurité de type
2. Il sera effectivement augmenter la sécurité de type dans votre code en vous alertant des conversions implicites. Le meilleur exemple dans l'instruction foreach
3. Maintient SEC principes en C#. C'est spécifiquement pour la déclaration des cas, pourquoi la peine de dire le nom deux fois?
4. Dans certains cas, il est à plat nécessaire. Exemple les types anonymes
5. Moins de frappe, sans perte de fonctionnalité.

http://blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx