BT

Votre opinion compte! Merci de bien vouloir répondre au sondage InfoQ!

Débat sur C# : quand devriez-vous utiliser var ?

| par Jonathan Allen Suivre 257 Abonnés , traduit par Julien Delhomme Suivre 1 Abonnés le 27 mai 2013. Durée de lecture estimée: 3 minutes |

Une note à nos lecteurs : Suite à vos retours, nous avons développé un ensemble de fonctionnalités qui vous permettent de réduire le bruit, tout en ne perdant pas de vue ce qui est important. Recevez des notifications en ligne et par e-mail en choisissant les sujets qui vous intéressent.

C#3 a introduit le mot clé "var". Ce mot clé laisse au compilateur le soin de déterminer le type d'une variable locale par inférence, dès lors que cette inférence peut se faire de façon non équivoque. Cependant, la question de quand l'utiliser fait débat.

Ilya Ryzhenkov de JetBrains, la société éditant des IDE, souligne certains bénéfices à l'utilisation de var,

  1. Il induit un meilleur nommage des variables locales.
  2. Il induit de meilleures API.
  3. Il force l'initialisation des variables.
  4. Il réduit le bruit au sein du code.
  5. Il économise le recours à la directive using.

Dare Obasanjo de RSS Bandit est en désaccord. Il a écrit une réponse à la prise de position d'Ilya Ryzhenkov après avoir constaté ce qu'il considère comme étant des changements nuisibles à son projet Open Source. Il contredit ainsi :

Il est intéressant de voir non seulement comment la plupart de ces "bénéfices" sont principalement stylistiques mais aussi qu'ils entrent en contradiction les uns avec les autres. Par exemple, l'argument disant que var mène à un meilleur nommage des variables locales veut en réalité dire qu'il contraint les développeurs à utiliser des NOMS DE VARIABLES LONGS, DANS LE STYLE DE LA NOTATION HONGROISE. Ce qui est plutôt amusant, c'est que ces longs noms de variables ajoutent du bruit au code de façon généralisée puisqu'il apparait partout où la variable est utilisée, plutôt que d'avoir une déclaration de type unique à l'endroit où la variable est déclarée. L'argument disant qu'il mène à de meilleures API est une variation sur ce thème puisqu'il soutient que si vous êtes poussés à utiliser des NOMS DE PROPRIETES PLUS LONGS ET DESCRIPTIFS (e.g. XmlNode.XmlNodeName au lieu de XmlNode.Name) alors vous améliorez votre code. Quelqu'un devrait informer les gens de ReSharper qu'encoder les informations de type dans les noms de variables, c'est mal ! Et que c'est précisément pourquoi nous utilisons un langage statiquement typé comme C#.

Encore une chose : l'argument selon lequel var encourage l'initialisation des variables est étrange étant donné que le compilateur C# renforce déjà cette contrainte. Plus important, le scénario courant consistant à initialiser une variable à null avant qu'elle soit utilisée n'est pas supporté par le mot clé var.

Dare appuie son raisonnement en citant cette ligne tirée de la référence officielle du langage C#,

L'utilisation excessive de var peut rendre le code source moins lisible pour les autres. Il est recommandé d'utiliser var seulement lorsque c'est nécessaire, c’est-à-dire lorsque la variable est destinée à stocker un type anonyme ou une collection de types anonymes.

Le grief selon lequel var réduit la lisibilité n'est pas partagé par tous. Arnon Rotem-Gal-Oz écrit :

Concernant la lisibilité du code, je préfère me concentrer sur des pratiques plus robustes, comme faire en sorte que les méthodes soient courtes, que les noms de méthodes et de variables soient parlants et d'avoir recours aux tests (qui vont réellement vous aider à comprendre comment se comporte le code…). Sans compter que, si vraiment vous en avez besoin, ReSharper vous indiquera le type au passage de la souris sur le mot clé var ;)

Chris Sutton semble aller encore plus loin en signifiant que le type n'a pas vraiment d'importance :

On suggère que vous ne devriez pas utiliser var lorsque vous ne connaissez pas le type. C'est là que je diverge, en opinion et en pratique. Regardez cet extrait de code

   var procs = from p in ServiceController.GetServices()
   where p.Status == ServiceControllerStatus.Running
   select p;
   procs.ToList().ForEach(p=> Console.WriteLine(p.ServiceName));

procs est certainement IEnumerable mais cela m'importe peu. J'ai avant tout besoin que procs soit une liste et que chaque élément de la liste ait une propriété appelée ServiceName. Le type sous-jacent est important pour le compilateur, mais les gens qui doivent lire du code ne sont pas des compilateurs, n'est-ce pas ?

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Se connecter à InfoQ pour interagir sur ce qui vous importe le plus.


Récupérer votre mot de passe

Follow

Suivre vos sujets et éditeurs favoris

Bref aperçu des points saillants de l'industrie et sur le site.

Like

More signal, less noise

Créez votre propre flux en choisissant les sujets que vous souhaitez lire et les éditeurs dont vous désirez suivre les nouvelles.

Notifications

Restez à jour

Paramétrez vos notifications et ne ratez pas le contenu qui vous importe

BT