I still think the "var" in C# is a really bad idea
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
It sometimes gets you out of a deep hole!
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
Agreed, that is bad code. But on the other hand consider this:
var myDictionary = new Dictionary<Guid, SomeClass>(sourceData);
which is more readable than this:
Dictionary<Guid, SomeClass> myDictionary = new Dictionary<Guid, SomeClass>(sourceData);
As with everything, it's use should be considered and appropriate. I use var only where the type is obvious from the right hand side of the statement (and for those anonymous linq types).
Simon
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
Well, I actually would keep the "var" and drop the "C#"... :rolleyes:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]modified on Friday, July 2, 2010 11:52 AM
-
Agreed, that is bad code. But on the other hand consider this:
var myDictionary = new Dictionary<Guid, SomeClass>(sourceData);
which is more readable than this:
Dictionary<Guid, SomeClass> myDictionary = new Dictionary<Guid, SomeClass>(sourceData);
As with everything, it's use should be considered and appropriate. I use var only where the type is obvious from the right hand side of the statement (and for those anonymous linq types).
Simon
At least in C# they didn't take an existing keyword and change the meaning...
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
.jpg wrote:
Consider this code: var num = MyMath.Add( 123, 789 ); By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types.
If type matters then don't use var. How hard can that be?
Todd Smith
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
Well how about this:
static void Main(string[] args)
{
SomeFunction(SomeClass.SomeOtherFunction(arg[0]));
}static void SomeFunction(int i)
{
throw new Exception();
}static void SomeFunction(double d)
{
Console.WriteLine(d);
}Don't look at the terrible coding style too much. This is just plain C#1 right? But do you know, without looking up SomeClass.SomeOtherFunction, what will happen? I sure don't.
-
Agreed, that is bad code. But on the other hand consider this:
var myDictionary = new Dictionary<Guid, SomeClass>(sourceData);
which is more readable than this:
Dictionary<Guid, SomeClass> myDictionary = new Dictionary<Guid, SomeClass>(sourceData);
As with everything, it's use should be considered and appropriate. I use var only where the type is obvious from the right hand side of the statement (and for those anonymous linq types).
Simon
Except that in the second example, after hitting spacebar after the "new", the editor fills in the rest, so either way, you have to type in the type. Uh. No pun intended. I still don't see the purpose of var except for Linq and/or lambda expressions. Marc
-
Except that in the second example, after hitting spacebar after the "new", the editor fills in the rest, so either way, you have to type in the type. Uh. No pun intended. I still don't see the purpose of var except for Linq and/or lambda expressions. Marc
Marc Clifton wrote:
xcept that in the second example, after hitting spacebar after the "new", the editor fills in the rest, so either way, you have to type in the type. Uh. No pun intended.
Notepad has never done this for me. ;P
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Except that in the second example, after hitting spacebar after the "new", the editor fills in the rest, so either way, you have to type in the type. Uh. No pun intended. I still don't see the purpose of var except for Linq and/or lambda expressions. Marc
Marc Clifton wrote:
var except for Linq and/or lambda expressions
Oh, so you can use it for other things as well :-O it never even occurred to me.
Never underestimate the power of human stupidity RAH
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
.jpg wrote:
you won't be able to know whether num is an int32, int16, float, double, or any other types
Much of the time, knowing the exact type doesn't matter (in the example you gave, you know it's probably a number). And you could find out by mousing over "Add", or by typing "num" (the tooltip will tell you the type). Of course, typing "int" isn't going to cause you much more trouble than typing "var", so it's probably more appropriate here to just type "int". Still, I wouldn't say what you have shown demonstrates why var in C# is "a really bad idea". In fact, it seems like a pretty good idea in many situations (covered by other posters above already).
-
.jpg wrote:
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types.
But the compiler will, and at the end of the day, that's what is important.
J4amieC wrote:
But the compiler will, and at the end of the day, that's what is important.
Is it? I think not, sir! What is most important in the long run is that the code is maintainable, as the costs of maintenance outweigh the costs of development (usually). That said, var is useful when used appropriately.
___________________________________________ .\\axxx (That's an 'M')
-
.jpg wrote:
Consider this code: var num = MyMath.Add( 123, 789 ); By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types.
If type matters then don't use var. How hard can that be?
Todd Smith
exactly my thought!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Well how about this:
static void Main(string[] args)
{
SomeFunction(SomeClass.SomeOtherFunction(arg[0]));
}static void SomeFunction(int i)
{
throw new Exception();
}static void SomeFunction(double d)
{
Console.WriteLine(d);
}Don't look at the terrible coding style too much. This is just plain C#1 right? But do you know, without looking up SomeClass.SomeOtherFunction, what will happen? I sure don't.
Good one! :laugh:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
The specification of
MyMath.Addis part of the code, right? So read that bit... And whatever you do, don't use a language like Haskell or Ocaml, which does real, powerful type deduction - it'll blow your mind...Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p CodeProject MVP for 2010 - who'd'a thunk it!
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
I like
varbecause it takes focus off the type, and places it on the variable name. With a good variable name var actually improves your code if you were to change the type later. Consider:int customerBalance = GetCustomerBalance();, which has to be changed todecimal customerBalance = GetCustomerBalance();after the function return is changed, wherevar customerBalance = GetCustomerBalance();would have worked both ways. If you have enough dicipline in variable names one wouldn't need to look at the types (mostly), andvarpromotes this (to a degree).____________________________________________________________ Be brave little warrior, be VERY brave
-
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
Agreed... So why don't we have some kind of Visual Studio option that does all the type-inference and replaces all those 'var's with actual inferred types? I thought the main purpose of 'var' was to increase productivity... Or, maybe the following syntax should be allowed:
Dictionary<string> myDictionary = new(StringComparer.OrdinalIgnoreCase);(E.g. no extra type declaration if selecting a constructor from the same class. Not very readable though if you're not used to it.) - DerHenker -
Consider this code:
var num = MyMath.Add( 123, 789 );
By just reading the code, you won't be able to know whether num is an int32, int16, float, double, or any other types. :^)
.jpg wrote:
var num = MyMath.Add( 123, 789 );
Once again, your example is a perfect example of PEBKAC, and not an example of a problem with var. If used as intended, 'var' is extremely useful. Your example is NOT an intended use. While it can be done, you are absolutely correct. You don't know what the return value will be. But, when used with LINQ, it is EXTREMELY useful, and that was really its intended purpose. It can also help in situations like this: SomeInsanelyLongNameThatNeverEnds<LongLongName, SuperLongNameAgain> someVar = new...you get the picture. Throw a var in there and it shortens it considerably without losing any information. That is really, IMHO, the only time to use var outside of LINQ, when you don't lose any information. The final point is...get ReSharper. If you are unsure of return values, but want to display them, type in 'var', and then select 'specify type explicitly' in ReSharper, and it puts the return type in there for you. VERY useful! I use that one all the time.