Var just makes it harder to read C# code. For example, the difference between...
int foo = object.GetSomething() vs
var foo = object.GetSomething()
The int makes it easy for you to instantly identify that foo is an integer. In the var example, what the fuck is foo? A string? A class? An integer? To find out, you must rely on Visual Studio's Intellisense and hover your mouse over foo for a few secons, before Visual Studio will tell you what type foo is. This slows your code reading considerably. And if you don't have Visual Studio, then you have to go waste time reading the documentation to figure out what type foo is.
Sure, it save your typing time, but, it waste other developer's reading time.
I see comments like this on var all the time, and I just don't understand the problem. It just means that 'foo' and 'GetSomething' are poorly named. If you had something like:
var name = GetFullName();
Then it's clear what's going on. If the code you're working with is so opaque that you can't understand what's going on without looking everything up, then the code is at fault, not a language feature. Especially as var is locally scoped.
I personally use var all the time, as does my team. We never complain about it. If you use something like F# where a lot of the time the types are 'invisible' then you'd see how powerful type inference can be. I for one hope that C# goes much further with it; being so explicit about specifying types is a major annoyance when the compiler knows what your intent is.
> And if you don't have Visual Studio, then you have to go waste time reading the documentation to figure out what type foo is.
Which you'd have to do nearly all the time anyway if you were using anything that doesn't provide 'intellisense'. If you choose to use a text editor with any language you need to look up the contract before use.
And lastly, it's needed if you're going to work with anonymous types.
Of course this is optional, so if there are times when there may be confusion it's easy to be explicit. But most of the time there is no need.
I'm trying my hand at getting back into some C# coding and found that apparently the language now has var. My first thought was why would a professional, statically typed language have var. Checking out the page I linked to in the submission, you can also do this cool if not slightly funky looking thing where it looks like an SQL predicate just reading from an ordinary array.
The 'cool but funky' thing is LINQ. Language Integrated Query. It can be used to query in-memory lists and arrays as well as build SQL to query a DB, or even query XML files.
It is C#'s support for monads.
In terms of var. It's best not to think of it as dynamic like javascript. You can't do this for example:
var a = 123;
a = "Hello";
The second line will throw an exception because 'a' is not a string, it's an int. So it's not dynamic like JS. It simply infers the type when it can so that you don't have to type it, otherwise its exactly the same.
Interestingly C# does have a dynamic aspect too, and that's with the 'dynamic' keyword.
dynamic x = 123;
x = "Hello";
That will work where the var example wouldn't. It's a rarely used feature, but comes in useful to avoid boilerplate when dealing with external 'stuff', like XML files, JSON, or REST responses.
> My first thought was why would a professional, statically typed language have var.
It might be because C++ has auto. Kind of related Java has Object.
I haven't figured out if people want languages like C++ to be a loose typed language and just be able to type cast anything to a single type. Boost does introduce the variant type - but it's usage seems very unintuitive. I kind of get what they were trying to do - but overall Boost libraries seem overly complex for what they are trying to solve.
I wrote my own variant type based on Ptype's variant [1] [2]. To me a variant shouldn't just be a container for any object - it should have some basic intelligence for built in types (like what to do when adding a string and an int - the result should be a string. Conversely - when adding an int and a string the result should be an int.).
thelastguy|10 years ago
int foo = object.GetSomething() vs var foo = object.GetSomething()
The int makes it easy for you to instantly identify that foo is an integer. In the var example, what the fuck is foo? A string? A class? An integer? To find out, you must rely on Visual Studio's Intellisense and hover your mouse over foo for a few secons, before Visual Studio will tell you what type foo is. This slows your code reading considerably. And if you don't have Visual Studio, then you have to go waste time reading the documentation to figure out what type foo is.
Sure, it save your typing time, but, it waste other developer's reading time.
louthy|10 years ago
I personally use var all the time, as does my team. We never complain about it. If you use something like F# where a lot of the time the types are 'invisible' then you'd see how powerful type inference can be. I for one hope that C# goes much further with it; being so explicit about specifying types is a major annoyance when the compiler knows what your intent is.
> And if you don't have Visual Studio, then you have to go waste time reading the documentation to figure out what type foo is.
Which you'd have to do nearly all the time anyway if you were using anything that doesn't provide 'intellisense'. If you choose to use a text editor with any language you need to look up the contract before use.
And lastly, it's needed if you're going to work with anonymous types.
Of course this is optional, so if there are times when there may be confusion it's easy to be explicit. But most of the time there is no need.
jebblue|10 years ago
louthy|10 years ago
It is C#'s support for monads.
In terms of var. It's best not to think of it as dynamic like javascript. You can't do this for example:
The second line will throw an exception because 'a' is not a string, it's an int. So it's not dynamic like JS. It simply infers the type when it can so that you don't have to type it, otherwise its exactly the same.Interestingly C# does have a dynamic aspect too, and that's with the 'dynamic' keyword.
That will work where the var example wouldn't. It's a rarely used feature, but comes in useful to avoid boilerplate when dealing with external 'stuff', like XML files, JSON, or REST responses.nadams|10 years ago
It might be because C++ has auto. Kind of related Java has Object.
I haven't figured out if people want languages like C++ to be a loose typed language and just be able to type cast anything to a single type. Boost does introduce the variant type - but it's usage seems very unintuitive. I kind of get what they were trying to do - but overall Boost libraries seem overly complex for what they are trying to solve.
I wrote my own variant type based on Ptype's variant [1] [2]. To me a variant shouldn't just be a container for any object - it should have some basic intelligence for built in types (like what to do when adding a string and an int - the result should be a string. Conversely - when adding an int and a string the result should be an int.).
[1] https://srchub.org/p/cppvariant/source/tree/tip/variant.h
[2] https://srchub.org/p/ptypes/source/tree/tip/src/pvariant.cxx