Discussion :

[same66]

Bonjour à tous,

simple question, je me demande s'il y a un intérêt à remplacer :

int maVariable = 6;
par
var maVariable = 6;

J'utilise resharper et ce dernier me conseille de passer int à var car le typage est implicite.

Il y a un gain en perf ? ou un intérêt quelconque ?

Merci

[Er3van]

Au contraire, il faut laisser int, le typage explicite est à utiliser autant que possible. Cela évite à ton compilateur de se poser la question.

Un petit lien MSDN

[same66]

Merci beaucoup

[calagan99]

La compilateur va utiliser le type le plus approprié à la compilation. Donc pas de problème de performance à utiliser var.
Pour la lisibilité, j'ai tendance, comme Er3van à préférer le typage explicite.

[BenoitM]

Au contraire, il faut laisser int, le typage explicite est à utiliser autant que possible. Cela évite à ton compilateur de se poser la question.

Un petit lien MSDN

et surtout au developpeur


ps : Je suis surpris par la proposition de resharper, ca doit etre un cas spécifique (Foreach peut-etre?)

[Nathanael Marchand]

Tout se joue à la compilation, un var sera remplacé par le type qui va bien, c'est l'inférence de type. L'executable généré ne differera pas et il n'y aura donc pas de problèmes de performances. Tout est dans le style de codage.
Personellement, j'ai dorénavant une forte tendance à toujours utiliser le var car d'une part j'estime que le type de variable n'est pas forcément intéressant (si les variables sont correctement choisies, var listOfPerson est un List<Person> et non pas un int) et de plus ca permet un refactoring simple.

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

List<Person> people = Repository.GetPeople();

Si sur GetPeople je décide dorénavant de retourner un IEnumerable<Person>, je dois tout changer mon code contrairement à ce bout de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var people = Repository.GetPeople();

Après, quand on manipule des types anonymes on a plus trop le choix, c'est obligatoire.

[Er3van]

Ça se défend..
Mais t'as le problème malgré tout.
Si tu fais sur ton objet des opérations qui sont propre à son type, par exemple :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

people.Add(new Person("toto"));

Avec var, tu n'auras plus l'erreur au niveau de la déclaration de ton objet mais uniquement au moment de l'appel à la méthode. Je ne trouve pas ça "mieux", mais effectivement, chacun son style de codage !

Après, pour les types anonymes, en effet il n'y a guère le choix.

[Bluedeep]

Avec var, tu n'auras plus l'erreur au niveau de la déclaration de ton objet mais uniquement au moment de l'appel à la méthode. Je ne trouve pas ça "mieux", mais effectivement, chacun son style de codage !

Non, puisque l'inference de type faite par la compilateur ne changera rien.
"var" ça reste quand même du typage statique, inféré certes, mais statique; C# n'est pas JavaScript

[Nathanael Marchand]

Non, puisque l'inference de type faite par la compilateur ne changera rien.
"var" ça reste quand même du typage statique, inféré certes, mais statique; C# n'est pas JavaScript

Je pense qu'il voulait dire au moment de la compilation mais sur la ligne de l'appel.
Cela dit, si ca compile plus car la méthode n'existe pas dans le nouveau type, c'est que c'est le refactoring qui est foireux et d'avoir changé tous les List<T> en IEnumerable<T> n'aura pas forcément ammené une information pertinente (voire aura généré du "bruit" pour le gestionnaire de revisions des sources)

[Bluedeep]

Je pense qu'il voulait dire au moment de la compilation mais sur la ligne de l'appel.

Après relecture, il s'avère que tu as sans doute raison. Mon message était donc sans objet (bon, ni le premier ni le dernier dans ce cas)

[Er3van]

Je pense qu'il voulait dire au moment de la compilation mais sur la ligne de l'appel.

C'était bien dans ce sens là !

et d'avoir changé tous les List<T> en IEnumerable<T> n'aura pas forcément ammené une information pertinente (voire aura généré du "bruit" pour le gestionnaire de revisions des sources)

On est bien d'accord...

=> Donc ça se résume à une choix du développeur en terme de préférence personnel?

[Nathanael Marchand]

Donc ça se résume à une choix du développeur en terme de préférence personnel?

Toutafé!

[Er3van]

Le "?" était en trop... y a des jours où mon clavier (c'est facile d'accuser le hardware hein?) n'est pas très en forme!