Pourquoi serait var une mauvaise chose?

StackOverflow https://stackoverflow.com/questions/545616

Question

J'ai discutais avec mes collègues l'autre jour et entendu que leur norme de codage leur interdit explicitement d'utiliser le mot-clé var en C #. Ils ne savaient pas pourquoi il était si et je l'ai toujours trouvé déclaration implicite d'être extrêmement utile lors du codage. Je ne l'ai jamais eu de problème à trouver à quel type de la variable a été (vous ne survolez la variable VS et vous obtiendrez le type de cette façon).

Est-ce que quelqu'un sait pourquoi ce serait une mauvaise idée d'utiliser le mot-clé var en C #?

Autres conseils

var q = GetQValue();

est en effet une mauvaise chose. Cependant, 

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

est parfaitement bien pour moi.

Le Bottomline est: utiliser des noms d'identification descriptifs et vous obtiendrez le long très bien

.

En sidenote: Je me demande comment traitent-ils des types anonymes lorsqu'ils ne sont pas autorisés à utiliser mot-clé var. Ou bien ils ne les utilisent pas tout à fait?

Dans la plupart des cas, lorsque utilise sensiblement (à savoir un type simple initialiseur où le type et la valeur sont les mêmes), il est très bien.

Il y a des moments où on ne sait pas que vous avez des choses brisées en le changeant - principalement, lorsque le type initialisées et le type de variable (d'origine) ne sont pas les mêmes, parce que:

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

Dans ce cas, vous pouvez avoir des ennuis avec une résolution de type - par exemple:

  • méthodes qui ont différents pour les surcharges deux types concurrents
  • méthodes d'extension qui sont définis différemment pour les deux types concurrents
  • membres qui ont été à nouveau déclarés (caché) sur l'un des types
  • inférence de type générique fonctionne différemment
  • Résolution de l'opérateur fonctionnera différemment

Dans ce cas, vous changez le sens du code, et 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 cache: 

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

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

Toutes les normes de codage des entreprises ont un sens, j'ai déjà travaillé pour une entreprise qui voulait préfixer tous les noms de classe avec le nom de l'entreprise. Il y avait une énorme reprise lorsque la société a changé son nom.

Tout d'abord, en règle générale, les normes de codage devraient être discutées et convenues par l'équipe, et le raisonnement derrière eux devraient être consignées par écrit, afin que chacun puisse savoir pourquoi ils sont là. Ils ne devraient pas être la sainte vérité d'un maître.

En second lieu, cette règle est probablement justifiée parce que code est plus que temps de lecture écrit . var accélère l'écriture, mais peut ralentir la lecture un peu. Il est de toute évidence pas une règle de comportement de code comme « initialiser les variables toujours » parce que les deux alternatives (écriture var et l'écriture du type) ont exactement le même comportement. Il est donc pas une règle critique. Je n'interdire var, je voudrais simplement utiliser « Préférez ... »

var est le dernier « comment mettre vos accolades » / notation hongroise / débat boîtier Camel. Il n'y a pas de bonne réponse, mais il y a des gens qui sont assis aux extrémités.

Votre ami est juste dommage qu'ils travaillent en dessous d'un des extrémistes.

Interdisant cela signifie tout à fait interdire l'utilisation des types anonymes (qui deviennent incroyablement utile que vous utilisez LINQ plus).

Ceci est la bêtise pure et simple à moins que quelqu'un peut formaliser une bonne raison de ne jamais utiliser des types anonymes.

Il peut nuire à la lisibilité si elle est mal utilisée. Cependant interdisant complètement est un peu étrange que vos collègues auront un moment difficile en utilisant des types anonymes sans elle.

Ceci est vraiment un problème de lisibilité avec votre code.

Ma préférence personnelle est de ne jamais utiliser « var » pour les types anonymes (en effet, si vous souhaitez utiliser des types anonymes à tous, vous aurez besoin d'utiliser var), et ceux-ci viennent principalement de requêtes LINQ. Dans ces cas, vous avez pas d'autre choix que d'utiliser var si votre requête projette dans un nouveau type (implicite et anonyme).

Cependant, C # 3.0 vous laisserez heureusement utiliser var où vous voulez, en dehors de LINQ et des types anonymes, par exemple: 

var myint = 0;
var mystring = "";

est parfaitement valide et Myint et mystring seront fortement typés par les valeurs inférées utilisées pour les initialiser. (Ainsi, myint est un System.Int32 et mystring est un System.String). Bien sûr, il est assez évident quand on regarde les valeurs utilisées pour initialiser les variables quels types ils seront tapés implicitement, cependant, je pense qu'il est encore mieux pour la lisibilité du code si ce qui précède ont été écrit: 

int myint = 0;
string mystring = "";

puisque vous pouvez voir immédiatement un coup d'oeil exactement quel type ces variables sont.

Considérez ce scénario un peu confus: 

var aaa = 0;
double bbb = 0;

Parfaitement code valide (si un peu non conventionnel), mais dans ce qui précède, je sais que bbb est un double, en dépit de la valeur d'initialisation paraissant être un int, mais aaa ne sera certainement pas un double, mais plutôt un int.

Vous pouvez envisager l'avis de Microsoft est pertinente, puisque C # est leur langue:

  

"Cependant, l'utilisation de var ne possède au moins le potentiel de rendre votre code plus difficile à comprendre pour les autres développeurs. Pour cette raison, la documentation C # utilise généralement var seulement quand il est nécessaire. "

Voir MSDN - Variables locales typées Implicitement (Guide de programmation C #) , dernier paragraphe.

Vous devez également savoir que var supprime le test de type de données de compilation sur l'affectation initiale. 

var x = "mistake";     // error not found by compiler
int x = "mistake";     // error found

Étant donné que la plupart des variables ne sont attribués qu'une seule fois, l'utilisation cohérente de var supprime presque tous les tests de type de données sur les affectations de variables.

Cela rend votre code vulnérable aux changements accidentels par exemple celles qui sont faites par des outils de fusion ou les développeurs fatigués.

frappe est grand Implicite, et les gens qui à plat l'interdisent d'endommager la productivité et code d'invitation fragile.

Il est presque comme le type de sécurité, duck typing compilateur vérifié, ce qui est très utile lorsque refactoring. Par exemple, si j'ai une méthode qui retourne une liste, et je refactoriser revenir IEnumerable, puis tous les appelants à cette méthode qui ont utilisé le mot-clé var et utiliser uniquement les méthodes IEnumerable sera très bien. Si je l'ai explicitement spécifié, par exemple, la liste, alors je dois aller et changer cela pour IEnumerable partout.

Il est évident que, si l'un des appelants implicites typage nécessitent des méthodes Liste, je vais me faire des erreurs de compilation quand je construis, mais si tel est le cas, je ne devrais probablement pas été de changer le type de retour de toute façon.

De Département de la Déclaration Département de Redondance (de Jeff < a href = "http://www.codinghorror.com/" rel = "nofollow noreferrer"> codage d'horreur):

  

"J'utilise la saisie variable implicite   quand et où il fait mon code   plus concis. Tout ce qui supprime   la redondance de notre code devrait être   agressivement poursuivi - jusqu'à et   y compris les langues de commutation. "

Je me pense que est vaut prendre au sujet, mais la création d'une ligne directrice complète sur le moment d'utiliser ou non serait surpuissant .

J'ai eu des cas (quand je foreach à travers une collection Table.Rows) lors de l'utilisation var a donné lieu à l'être du type d'une classe de base plutôt que le type DataRow réelle. C'est la seule fois que je l'ai eu du mal avec var.

'var' est d'être clair

Le principal débat sur l'opportunité d'utiliser le mot-clé var ou non sur la façon lisible le code est à vous et à d'autres développeurs.

Tout comme si vous étiez en train d'écrire une histoire il n'y a pas de bonne réponse définitive. Mais regardons quelques exemples en anglais simple.

  

Jake dit bonjour à Bill. Il ne l'aimait pas alors il se retourna et alla dans l'autre sens.

Qui est allé dans l'autre sens? Jake ou le projet de loi? Dans ce cas, « Jake » et « Bill » sont comme le nom du type. Et « il » et « lui » sont comme le mot-clé var. Dans ce cas, il pourrait aider à être plus précis. Ce qui suit par exemple est beaucoup plus claire.

  

Jake dit bonjour à Bill. Jake n'a pas aimé Bill alors il se retourna et alla dans l'autre sens.

Dans ce cas, être plus précis en la phrase plus claire. Mais cela va pas toujours être le cas. Dans certains cas, être précis, il est plus difficile à lire.

  

Bill aime les livres, si Bill est allé à la bibliothèque et le projet de loi a sorti un livre que Bill a toujours aimé.

Dans ce cas, il serait plus facile de lire la phrase si nous avons utilisé « il » et dans certains cas, laissés à son nom tous ensemble, cela est l'équivalent d'utiliser le mot-clé var.

  

Bill aime les livres, alors il est allé à la bibliothèque et a sorti un livre qu'il a toujours aimé.

Ces analogies couvrent l'essentiel, mais ils ne disent pas toute l'histoire. Voir dans ces exemples il n'y avait qu'une seule façon de se référer à la personne. Que ce soit avec leur nom, par exemple le projet de loi ou d'une manière plus générale, comme « il » et « lui ». Mais nous ne travailler avec un seul mot.

Dans le cas du code que vous avez deux « mots », le type et le nom de la variable. 

Person p = GetPerson();

La question devient maintenant est là il suffisamment d'informations pour que vous puissiez déterminer facilement ce que p est? Sauriez-vous toujours ce que les gens est dans ce scénario: 

var p = GetPerson();

Que diriez-vous celui-ci: 

var p = Get();

Que diriez-vous celui-ci: 

var person = Get();

Ou celui-ci: 

var t = GetPerson();

Ou celui-ci: 

var u = Person.Get();

Si le mot-clé var fonctionne dans un scénario donné dépend beaucoup du contexte du code, comme ce que les noms des variables, des classes et méthodes, ainsi que la complexité du code.

Personnellement, je préfère utiliser le mot-clé var il est plus complet me . Mais je aussi tendance à nommer mes variables après le type, donc je ne suis pas vraiment perdre aucune information.

Cela dit parfois je fais des exceptions, telle est la nature de tout complexe, et le logiciel est rien sinon compliqué.

Voici les résultats d'un test j'ai couru sur l'efficacité de var contre la saisie explicite: 

  private void btnVar_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        var test = "Test";
        test.GetType();
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();
    }

    private void btnString_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        string test = "Test";
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();

    }

Premier résultat Label est: 00:00:00 000034

Deuxième résultat Label est: 00:00:00 00008

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top