The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I use var almost exclusively these days.
I started out using it sometimes, but then I started using it more and more.
To me, it just seems nice to have all my vars lined up nicely
Some people thing the var keyword isn't strongly typed, but it is (we have dynamic for that).
It's only absolutely necessary to use var when working with anonymous types (still strongly typed!).
The C# "var" construct and other such constructs in both C# and VB.NET are merely short-cuts or the usage of system defaults.
This makes for very ambiguous code over the length of an application's development.
This is why I don't even use the generic list-type and still use array-lists instead. Despite the slight performance decreases (which most will not notice since such constructs often do not contain thousands of objects or items in general), having easy to read strongly typed code makes my applications much more easily maintainable.
Sr. Software Engineer
Black Falcon Software, Inc.
The last place I worked would fail you in code reviews if you did not use var. Their (ill) logic was something to do with a design pattern, and when Entity Framework would cough on var, they added lines of code to get it to pass instead of just using the correct type.
I (almost) only use var for non-production code, when I'm writing from whole cloth and doing initial diagnostics. As the code matures, I replace (almost) all instances of var with the actual types. Great way to force you to review and refactor before release.
For very long types, I'll use var, but only when the type is already included in the same location, like a declaration and instantiation.
Apart from the obvious (it saves typing and you have a set maximum number of keystrokes you can make in your life), it also allows for alignment which makes things easier to read (we're better with vertical scanning than horizontal scanning - for more see: https://www.youtube.com/watch?v=ZsHMHukIlJY and also there's just plain less to read!) but also because consuming code is more likely to survive a refactor intact: changing return type to something with similar shape means no consumer changes, renames of classes don't have to alter as many lines of code.
Since it's syntactic sugar, it costs nothing at runtime and it's normally one of the first automated fixes I do in a file when I enter legacy code.
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing
I've read that convention is to use "var" when the type of variable is apparent by reading the code. If you printed out this code it would still be pretty obvious that "url" is a string. If you can't tell the type by reading the code then the actual type should be used. It is lazy but if it eliminates some redundancy and makes coding a little quicker than it's a good thing. I personally follow the convention above but I know some people use var for everything.
The problem is that it sometimes becomes a style guideline in teams. I have seen that happening before, which is just stupid to me.
"Oh, but you can just hover over it and you will see". This mindset can be a real nightmare on code reviews.
I hate the laziness that motivated most var uses I have seen. People don't even know why var was created (to support anonymous types).
There are though, as some people have already mentioned, some situations where var makes the code cleaner. But I actually never seen that kind of diligence, so wherever I could I abolished the used of var for non anonymous types.
To make matters worse, stupid resharper (that some people like to use) has the default setting that everything should be var. So it pretty much converts the new-comers to the var mindset from the start.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
In my experience, the need to use var arises from wanting to hide the sometimes lengthy names of collection iterators in foreach declarations. Especially when Linq is used to get the collection, the declaration can become messy.
But you now how it goes: first it's to shorten lengthy iterator names, then lengthy class names, then pretty much everywhere because it looks more consistent for some people.
I can support the use in foreach declarations, but everywhere else it's more of an annoyance.
I never understood the desire to hide stuff like this. It's like an unspoken commitment to never refactor whatever is hidden.
There is no advantage. If you just write a scribble, then always using var is Ok. But if you write production-level code, var is sloppy style and thus an absolute no-go. Before IntelliSense was able to automatically convert the var's in your source code to the correct type, var was even an evidence of a programmer not knowing what type they're using.
Only exception: Use var to avoid writing the same type twice in the same line.
List<string> list = new List<string>();
var list = new List<string>();
Because then, when you want to change the type, let's say from List to HashSet, you only have to change it once. IntelliSense also suggests this, at least in VS 2017.
I threw 'of all' in there as a little red herring to add a little ambiguity as to whether the target word was ALL or ETYMA. Connector words are generally allowed and have nothing to do with the cryptic meaning.