Je regarde le prochain Visual Studio 2017 .
Sous la section intitulée Productivité boostée , une image de Visual Studio est utilisée pour remplacer toutes les occurrences de var par le type explicite.
Le code présente apparemment plusieurs problèmes que Visual Studio a identifiés comme «nécessitant une correction».
Je voulais vérifier ma compréhension de l'utilisation de var en C # alors j'ai lu un article de 2011 par Eric Lippert intitulé Uses and abuse of typ implicit .
Eric dit:
- Utilisez var quand vous devez; lorsque vous utilisez des types anonymes.
- Utilisez var lorsque le type de la déclaration est évident à partir de l'initialiseur, surtout s'il s'agit d'une création d'objet. Cela élimine la redondance.
- Envisagez d'utiliser var si le code met l'accent sur le «but commercial» sémantique de la variable et minimise les détails «mécaniques» de son stockage.
- Utilisez des types explicites si cela est nécessaire pour que le code soit correctement compris et maintenu.
- Utilisez des noms de variables descriptives, que vous utilisiez ou non «var». Les noms de variable doivent représenter la sémantique de la variable, pas les détails de son stockage; «DecimalRate» est mauvais; «InterestRate» est bon.
Je pense que la plupart de l' utilisation de var dans le code est probablement correcte. Je pense que ce serait ok de ne pas utiliser var pour le bit qui lit ...
var tweetReady = workouts [ ... ]
... parce que ce n'est peut-être pas 100% immédiat de quel type il s'agit mais même alors je sais assez rapidement que c'est un boolean.
L' utilisation var pour cette partie ...
var listOfTweets = new List<string>();
... me semble exactement comme une bonne utilisation de var car je pense qu'il est redondant de faire ce qui suit:
List<string> listOfTweets = new List<string>();
Bien que basée sur ce qu'Eric dit, la variable devrait probablement être des tweets plutôt que listOfTweets .
Quelle serait la raison de changer la totalité de l' varutilisation ici? Y a-t-il un problème avec ce code qui me manque?
la source
varici vont bien. Vous pourriez éventuellement en changer un - mais même dans ce cas, je pense que ce n'est pas vraiment nécessaire. Pourquoi les changer tous en type explicite?varsont été marqués de la même manière; avec la même croix de mise en garde à côté d'eux et un soulignement rouge. On peut supposer que Visual Studio souhaite les corriger tous de la même manière. A moins que je ne me trompe.Réponses:
TL; DR: non, Microsoft ne décourage pas l'utilisation de 'var' en C #. L'image manque simplement de contexte pour expliquer pourquoi elle se plaint.
Si vous installez VS2017 RC et ouvrez le panneau Options et allez
Text Editor -> C#, vous verrez une nouvelle section:Code Style. Ceci est similaire à ce que ReSharper offre depuis un certain temps: un ensemble de règles configurables pour les styles de codage.Il comprend trois options autour de l'utilisation de
var: pour les types intégrés, lorsque le type de variable est apparent et "Ailleurs". Dans chaque cas, vous pouvez spécifier "préférer le type explicite" ou "préférer var" et définir le niveau de notification sur "aucun", "suggestion", "avertissement" ou "erreur":la source
var.var, donc je ne m'inquiète pas beaucoup du point de vue de MS sur cette question.Je pense que vous en lisez trop. Il existe donc une fonctionnalité qui vous permet de remplacer les utilisations du typage implicite par des annotations de type explicites, et vous en concluez que le typage implicite est déconseillé. Il existe également une fonctionnalité permettant de compiler le bytecode C♯ en CIL. En concluriez-vous que C♯ est déconseillé et que nous devrions tous écrire le bytecode CIL à la place? Probablement pas.
Microsoft montre simplement la profonde compréhension que l'IDE a de votre code. Il peut même écrire vos types sans que vous ayez à les épeler. C'est ça.
Il s'agit simplement d'un bon exemple de démonstration des capacités de compréhension de code de l'EDI. Il est petit et autonome (contrairement à l'affichage d'un refactoring plus important), il est disponible dans toutes les éditions et applicable à tous les développeurs (contrairement à certaines des fonctionnalités de visualisation architecturale certes très impressionnantes qui ne sont disponibles que dans Ultimate et ne s'appliquent pas à une partie importante des utilisateurs potentiels de VS qui n'auront jamais de projets aussi importants), et bien que ce soit très simple (il fait littéralement exactement la même chose
csc.exedepuisvara été introduit), il semble certainement impressionnant, en particulier pour quelqu'un qui ne comprend pas vraiment la dactylographie implicite et l'inférence de type (ou qui essaie de google "inférence de type" et est submergé par des termes comme Hindley-Milner, l'unification, le retour en arrière, alors qu'en fait inférence seule locale C♯ est extrêmement simple et direct).Donc, en bref: c'est une façon flashy de montrer une fonctionnalité IDE.
la source