Au-delà de l'utilisation évidente de var avec LINQ, je l'utilise aussi pour abréger les déclarations de variables poilues pour plus de lisibilité, par ex :
var d = new Dictionary<string, Dictionary<string, Queue<SomeClass>>>();
En général, la frappe statique me procure une sorte de confort (faute d'un meilleur terme) qui me fait hésiter à l'abandonner. J'aime avoir l'impression que je sais ce que je fais lorsque je déclare une variable. Déclarer une variable, ce n'est pas seulement dire quelque chose au compilateur, c'est dire quelque chose à la personne qui lit votre code.
Laissez-moi vous donner un exemple. Supposons que j'ai une méthode qui renvoie un List<string> . Ce code est certainement correct, et je pense que c'est la façon dont 90% des développeurs C# l'écriraient probablement :
List<string> list = MyMethod();
Évidemment, non ? En fait, voici un endroit que vous pourriez tout aussi bien utiliser var .
C'est vrai. Mais ce du code ne se contente pas de déclarer une variable, elle me dit ce que la personne qui l'a écrite a l'intention de faire :
IEnumerable<string> list = MyMethod();
Le développeur qui a écrit ce code me dit : "Je ne vais pas modifier cette liste, ni utiliser un index pour accéder à ses membres. Tout ce que je vais faire, c'est itérer sur cette liste". C'est beaucoup d'informations à faire passer dans une seule ligne de code. C'est quelque chose que vous abandonnez si vous utilisez var .
Bien sûr, vous ne l'abandonnez pas si vous ne l'utilisiez pas au départ. Si vous êtes le genre de développeur qui écrirait cette ligne de code, vous savez déjà que vous n'utiliseriez pas la fonction var là.
Editar:
Je viens de relire le post de Jon Skeet, et cette citation d'Eric Lippert m'a sauté aux yeux :
Les locals implicitement typés ne sont qu'un petit moyen de minimiser le comment et de mettre l'accent sur le quoi.
Je pense qu'en fait, dans de nombreux cas, utiliser le typage implicite revient à laisser le quoi implicite. C'est juste bien de ne pas s'attarder sur le quoi. Par exemple, je vais écrire une requête LINQ comme :
var rows = from DataRow r in parentRow.GetChildRows(myRelation)
where r.Field<bool>("Flag")
orderby r.Field<int>("SortKey")
select r;
Quand je lis ce code, une des choses que je pense en le lisant est " rows est un IEnumerable<DataRow> ." Parce que je sais que ce que les requêtes LINQ retournent est IEnumerable<T> et je peux voir le type d'objet sélectionné juste là.
C'est un cas où le quoi n'a pas a été rendu explicite. Il m'a été laissé le soin de déduire.
Maintenant, dans environ 90% des cas où j'utilise LINQ, cela n'a pas la moindre importance. Parce que 90% du temps, la prochaine ligne de code est :
foreach (DataRow r in rows)
Mais il n'est pas difficile d'imaginer un code dans lequel il serait très utile de déclarer rows comme IEnumerable<DataRow> - où de nombreux types d'objets différents sont interrogés, il n'est pas possible de placer la déclaration de la requête à côté de l'itération, et il serait utile de pouvoir inspecter rows avec IntelliSense. Et c'est une question de quoi, pas de comment.
