BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Débat sur C# : quand devriez-vous utiliser var ?

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

Favoris

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

Contenu Éducatif

BT