Are people abusing "var"?

[Gareth Erskine-Jones]

var can make things more readable when the RHS is explicit about the type it
returns. But when the RHS is not explicit it makes things less readable, it
introduces uncertainty.

I don't disagree. I do think there is a greater degree of subjectivity
here than you think though - as you say, when the RHS explicitly shows
the type then I don't see the problem - but at least one poster has
objected to:

var i = 2;

where the type of the RHS is perfectly clear (although in this case I
wouldn't use var because I don't see any particular benefit).

My personal practice, in those cases where use of var is optional, is
to explicitly specify the type. I then tend to look back through the
code and replace explicit types with var where I think it improves
clarity without introducing any potential problems.

 

[Anthony Jones]

message

On Tue, 25 Nov 2008 11:20:10 -0500, "Nicholas Paldino [.NET/C# MVP]"

Frank,

I agree with most, that var should not be used when you know the
type
you are working with. I trust the type inference, actually, but it's
more
about the readability of the code for me.

Oddly, it's all about the readability of the code for me - and most of
the time I find it more readable with var.

var can make things more readable when the RHS is explicit about the type
it
returns. But when the RHS is not explicit it makes things less readable,
it
introduces uncertainty.

I don't disagree. I do think there is a greater degree of subjectivity
here than you think though - as you say, when the RHS explicitly shows
the type then I don't see the problem - but at least one poster has
objected to:

var i = 2;

where the type of the RHS is perfectly clear (although in this case I
wouldn't use var because I don't see any particular benefit).

My personal practice, in those cases where use of var is optional, is
to explicitly specify the type. I then tend to look back through the
code and replace explicit types with var where I think it improves
clarity without introducing any potential problems.

Yikes!

What type is 2. Signed Byte, Byte, Unsigned Int, Int, Long, decimal? var
by its very nature introduces ambiguity.
When a developer reads:-

var a = 2;

They think "a is assigned 2, 2 will be an int, the type of a will be an
int".

When a developer reads:-

int a = 2;

They think "a is an int, a is assigned 2"

Which has greater clarity? (Yes this is microscopic in terms of other
things the developer needs to think but readablity is about the accumulation
of many small issues).


You consider 'less characters' == 'greater clarity' ?

 

[Gareth Erskine-Jones]

message
On Tue, 25 Nov 2008 11:20:10 -0500, "Nicholas Paldino [.NET/C# MVP]"

Frank,

I agree with most, that var should not be used when you know the
type
you are working with. I trust the type inference, actually, but it's
more
about the readability of the code for me.

Oddly, it's all about the readability of the code for me - and most of
the time I find it more readable with var.



var can make things more readable when the RHS is explicit about the type
it
returns. But when the RHS is not explicit it makes things less readable,
it
introduces uncertainty.

I don't disagree. I do think there is a greater degree of subjectivity
here than you think though - as you say, when the RHS explicitly shows
the type then I don't see the problem - but at least one poster has
objected to:

var i = 2;

where the type of the RHS is perfectly clear (although in this case I
wouldn't use var because I don't see any particular benefit).

My personal practice, in those cases where use of var is optional, is
to explicitly specify the type. I then tend to look back through the
code and replace explicit types with var where I think it improves
clarity without introducing any potential problems.

Yikes!

System.Int32 surely.

You consider 'less characters' == 'greater clarity' ?

It depends on the situation...