|
What I did intend to convey is that - from a scientific point of view - important things are missing, i.e. the "why X?" is never answered.
For example:
Why should one use var customer = new Customer(); instead of Customer customer = new Customer(); ? Someone may claim that customer is self-explanatory. Smalltalk ppl would also claim that type inference is awesome because it makes rapid prototyping more rapid. By some means or other they are right because you can decrease redundancy...
|
|
|
|
|
The intention of the article is to consolidate a best practice of using or not using 'var'. Now, first 7-8 line of the articles talks about the reason and explanation. Point to note here is that, using var instead of an explicit type does not have any serious impact like performance etc. Only thing it impacts is readability. And I have mentioned it in the beginning only. I am still not able to understand what was it "poor because of ... explanations and proofs (by concept). " to you.
Now to answer to your example
"Why should one use var customer = new Customer(); instead of Customer customer = new Customer();?"
Below is my response, an excerpt from the article itself
"... it is not always the best thing to use var. While using ‘var’ can help developers to avoid all the type declarations for local variables, it has impact on code readability.
...
Consider code readability and maintainability while making a choice between ‘var’ and explicit type. "
Now if the question here is to debate between "var customer = new Customer();" with "Customer customer = new Customer();", which is more readable. For me it makes sense to suggest something, which is more common and have a wide acceptance. Its so obvious to look at the left of a variable declaration to know its type. Isn't it?
|
|
|
|
|
Choosing whether to use var or not is not only a question of readability and maintainability. Even (compiling, not runtime) performance is a problem because the time is in worst-case exponential [1].
[1] J. Palsberg and M.I. Schwartzbach, "Object-Oriented Type Inference," Proc. ACM Conf. Object-Oriented Programming: Systems, Languages and Applications, pp. 146-161, Phoenix, AZ, Oct. 1991.
|
|
|
|
|
You mean theoretically, right?
Otherwise its compiling performance penalty limit to zero. This is subtle, when making a suggestion towards best practice, I feel.
Additionally how much importance compiling performance penalty has to this article, you think?
|
|
|
|
|
Best practise is mainly important in enterprise systems. These systems tend to consist of millions of lines of code. Ask someone at e.g. SAP how long it takes to compile an application. Some will answer "1 to 7 days". If you can avoid 1-12 hours, why not?
Best practise is always best practise and not only for small systems.
|
|
|
|
|
There is never a best practice that suits all. One size does not fit everyone. That is why there is a term named 'Tailoring'.
When we make a general suggestion on best practice, we usually take account of the common, and not the exceptions.
For e.g. FxCop makes a general suggestion 'Do not catch generic exception types' but there are many occurrences where we are bound to do that (for whatever reasons).
Further, you believe changing implicit to explicit typing would save that 4% - 7% percentage build time. That is far from reality. Try it your self, compiling 10000 line of code declaring variables explicitly vs 10000 lines of code declaring variables implicitly. Its not even in two decimal fraction. What impact are you talking about then?
|
|
|
|
|
Please cite your source as to how implicit typing has anything to do with boxing/unboxing? Boxing/Unboxing has everything to do with treating value types as reference types.
int i = 0; // <- no boxing here?
var i = 0; // <- no boxing here either
|
|
|
|
|
I think I have addressed this issue in the other response. Anyways, the reason behind bringing in the 'boxing/un-boxing' context is that, previously implicit typing (or to be more specific, using a common type to store any type instance) was done using boxing. Therefore, even if developers wanted to use implicit types it was not possible without having to compromise the performance. So, it made sense for me, to mention that now with 3.0 implicit typing is possible without the cost since 'var' was introduced without a new CLR version!!
modified on Thursday, November 5, 2009 4:12 AM
|
|
|
|
|
*Sigh* you are still going on about how var (implicit typing) and Boxing and Unboxing are the same thing! They are not!.
Please take some time and read this MSDN article, Boxing and Unboxing (C# Programming Guide). And then go and re-read PCoffey's comment on your article, where he/she posts some IL to prove they are not the same.
I <think< i=""> where you are getting confused is the fact that boxing is implicit in C#, but that has nothing to do with implicit typing.
modified on Thursday, November 5, 2009 2:26 PM
|
|
|
|
|
I am sorry, but your fundamentals are wrong!
I want to say it loud and clear
"var and implicit typing are the same thing! Yes, They are same at IL!."
Please read carefully, before you say something:
You wrote:
"PCoffey's comment on your article, where he/she posts some IL to prove they are not the same."
But here is what PCoffey has actually said:
the 2 methods produce the same IL:
.method private hidebysig static void CreateImplicitInteger() cil managed<br />
{<br />
.maxstack 1<br />
.locals init ([0] int32 i)<br />
IL_0000: nop<br />
IL_0001: ldc.i4.2<br />
IL_0002: stloc.0<br />
IL_0003: ret<br />
}
and
.method private hidebysig static void CreateExplicitInteger() cil managed<br />
{<br />
.maxstack 1<br />
.locals init ([0] int32 i)<br />
IL_0000: nop<br />
IL_0001: ldc.i4.2<br />
IL_0002: stloc.0<br />
IL_0003: ret<br />
}
Further, I think, you need a lot of technical maturity and I suggest you to brush up your fundamentals. Then come back and re-read this, it will make sense to you.
Ideally your comment should be removed from this article as it may mislead others.
|
|
|
|
|
Sorry that was a typo, I've fixed my origional comment. And when I said prove they are not the same, I meant boxing of an int and using var to declare an int , which by your logic should be the same thing.
So you are standing by this quote:
"int i = 2 can now be written as var i = 2, without having to worry about the overhead for boxing/un-boxing."
EDIT:
Here's another quote from you:
"The reason behind bringing in the 'boxing/un-boxing' context is that, previously implicit typing (or to be more specific, using a common type to store any type instance) was done using boxing (for the primitive types). Therefore, even if developers wanted to use implicit types it was not possible without having to compromise the performance. So, it made sense for me, to mention that now with 3.0 implicit typing is possible without the cost, since 'var' was introduced without a new CLR version! "
Primitive types (actually called value types) ARE NOT boxed in C#. Maybe you come from a Java would where everything derives from Object , but this is not the case in C#. Value types e.g int are stored as such and are not boxed into Object .
EDIT2:
From the C# 2.0 spec:
-------------------
8.2 Types
C# supports two kinds of types: value types and reference types. Value types include simple types (e.g., char, int, and float), enum types, and struct types.Reference types include class types, interface types, delegate types, and array types.
Value types differ from reference types in that variables of the value types directly contain their data, whereas variables of the reference types store references to objects.
-------------------
modified on Thursday, November 5, 2009 2:45 PM
|
|
|
|
|
dequadin wrote: I meant boxing of an int and using var to declare an int, which by your logic should be the same thing.
You have totally misunderstood! Its lunatic to even write such statements.
You not only have misunderstood the statement but also the essence of the article. Talking few line about var is just contextual. I do not intent to explain whats var and why was it introduced, in this article. It just about best practice on using or not using var. Knowledge of var is an implicit requirement for a reader to make sense out of this article.
dequadin wrote: Primitive types (actually called value types) ARE NOT boxed in C#.
dequadin wrote: Value types e.g int are stored as such and are not boxed into Object.
What happens below
Object i = 2;
No boxing?
I suggest you to re-read the article, once you have a clear concept of var and boxing.
|
|
|
|
|
Okay lets take a few steps back. Just to clarify, my issue with this article is this line:
"int i = 2 can now be written as var i = 2 , without having to worry about the overhead for boxing/un-boxing."
So what you are saying is that using var to declare and int :
var i = 2;
Saves the overhead in boxing like this statement:
Object i = 2;
But the two statements are completely different. Because var i = 2; and int i = 2; are exactly the same thing? So your statement is surely false?
Here's a code snipit:
static void SomeIntFunction(int i) {}
static void SomeObjectFunction(Object i) {}
static void Main(string[] args)
{
Object i = 2;
var l = (Object)2;
var j = 2;
int k = 2;
SomeIntFunction(i);
SomeObjectFunction(i);
SomeIntFunction(l);
SomeObjectFunction(l);
SomeIntFunction(j);
SomeObjectFunction(j);
SomeIntFunction(k);
SomeObjectFunction(k);
}
So where's the saved boxing overhead there?
When you give this example:
What happens below
Object i = 2;
There you are declaring a Object which is a reference type. So that would be the same as saying:
var i = (Object) 2;
|
|
|
|
|
I would say, you have limited technical maturity. I am repeatedly mentioning that, I do not intent to explain neither var nor boxing in this article. It just about best practice when using 'var', and therefore this article requires the reder to have the understanding of var.
Read this, I wrote in my previous comment
<blockquote class="FQ"><div class="FQA">ATANU.PODDER wrote:</div>Anyways, the reason behind bringing in the 'boxing/un-boxing' context is that, previously using a common notation to store any (value) type instance was done using boxing. Therefore, even if developers wanted to use such notation it was not possible without having to compromise the performance. So, it made sense for me, to mention that now with 3.0 implicit typing is possible without the cost since 'var' was introduced without a new CLR version!!
;</blockquote>
When you read some thing, try to get the spirit of the content, with your technical maturity!
|
|
|
|
|
You are refusing to listen to reason. Myself and numerous others have tried to show you your error. You ridicule my technical knowledge without actually reading and responding to my specif points.
I have flagged this article for review and and do not wish to take this further in the comments.
|
|
|
|
|
That is why I have mentioned "When you read some thing, try to get the spirit of the content...", you are stuck in just one sentence. That is where I felt you need maturity.
|
|
|
|
|
You said:
2. Do not use ‘var’ to .
a) refer known types.
eg. var customer = new Customer(); //Do not use
var numberList = new int[] { 1, 2, 3, 4, 5 }; //Do not use.
But I think this is a personal choice. var customer = new Customer() will not make the code unreadable, as the type is clearly visible in the same line.
And, for the second example:
var numberList = new int[] { 1, 2, 3, 4, 5 };
For me, the problem is the name numberList, which should be numberArray. The var or the int[] will not change anything.
|
|
|
|
|
As a common tendency we look at the left-side of a variable declaration to know its type.(Any programming language, you take, follows this notation.) Now if you suggesting look at the right to know the type, it is your own choice. But when the readability is concerned I feel its better to follow the usual notations.
And on the second issue of int[], whether you mention it as numberList or something else, I do not intent to make a suggestion on that in this article. A variable naming best practice(/ naming guideline) document would address that. My intention was here to make a suggestion that, do not to use var instead of int[]. I still stand by on that opinion for the very same reason as mentioned above.
|
|
|
|
|