I freaking HATE var!!

[Jon Davis]

Bill Wagner posted something here ..

http://msdn2.microsoft.com/en-us/vcsharp/default.aspx

"Local Type Inference, Anonymous Types, and var"
"Of all the features in C# 3.0, local type inference is generating the most
questions and misunderstanding. You know, 'var'. The fact is local type
inference is not as scary as it seems. In fact, you're not losing strong
typing. It's a simple time saver that is actually necessary to support
anonymous types."

Great. I appreciate that it's "necessary" to support LINQ (and LINQ is the
only major reason why it's necessary to support anonymous types).

Well then I guess my issue is with anonymous types. But I dislike var. It is
stinky to my nostrils. Bill can argue till the cows come home that it's
still strongly typed and produces MSIL that is no different than C# 2.0
code. I don't care, it's not the MSIL that I have to stare at all day long.

It was only a couple years ago that I was running around singing the praises
of Microsoft and celebrating the wonderous, magical LINQ invention (back
then it was a Microsoft Research invention, C-Omega). Finally, SQL and C#
would be beautifully merged syntactically. So don't get me wrong, I
understand and appreciate LINQ's value.

But I also understand and appreciate the hell I went through, and why I am
so glad I went through it, to wean myself off of Visual Basic 6.0
(Variant-land) and javascript and vbscript, and into Java and C#. In gross
celebration of lessons learned, I hacked together a silly Variant object for
C#, just for fun.
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=2854

It didn't take long that I began really appreciating strongly typed
declarations. It had nothing to do with performance. It had little to do
with stability. It had mostly to do with the fact that as I'm scrolling up
and down in my code, or when I right-click a variable and choose "Go To
Definition", I immediately saw what the heck it was. Not what it was named.
Not what was assigned to it. But what it was.

So var produces strongly-typed MSIL. Great. But it's still anonymous.

Introducing var forces us to revert back to the old Hungarian notation style
naming conventions--that is, variables will have to have their types
inferred in the name. Yes, the type is strongly typed at compile-time. And
if Microsoft builds Visual Studio right, yes, IntelliSense tooltips will
reveal what type a variable is. But what if we don't want to hover over the
variable with the mouse? What if we're not using Visual Studio? When editing
code, if you have to do extra work of any sort to discover the type of a
variable, productivity is lost.

The biggest grief of var is that it's really only useful for LINQ+SQL, but
it will compel Variant-style VB coders and javascript script kiddies to
dilute the somewhat more disciplined structure of C# for no good reason.
Normal declarations that do not involve LINQ and could do just as well with
a standard type reference will use var instead....

var doc1 = myComplexObject.GetDoc();
// oh, by the way, GetDoc() returns a System.Xml.XmlDocument

var doc2 = myOtherObject.GetDoc();
// oh, and um, GetDoc() returns a System.Windows.Forms.HtmlDocument

What's wrong with this picture? I'll tell you what's wrong: "var" sucks!!
There is nothing here that makes what doc1 and what doc2 are. The method
names of each object aren't necessarily wrong. But now they'd have to be
renamed to expose the type of data being returned. Where is the advantage?

Bill makes the lousy argument:
<quote>
string[] words = { "cherry", "apple", "blueberry" };

var sortedWords =
from w in words
orderby w
select w;

It's fairly obvious that sortedWords is some sequence of strings. (It's
actually a System.Query.OrderedSequence<string, string>). In my opinion,
OrderedSequence<string,string> doesn't add any new information for me when I'm
trying to read this code. In fact, I think it's clearer with the var
keyword.
</quote>

No, Bill, when you hide the declaration of the "words" variable, it is not
obvious that sortedWords is some sequence of strings. What if a Words was an
array of a complex type called Word? And why are you limiting yourself to
words in these samples? How often do we have the luxury of working with
objects that are "obviously" composed of strings or arrays or collections
thereof?

Most often, types consist of all kinds of weird values. Even when pounding
against a SQL database table, a particular table could have an ID column
that could be an integer, it could be a string, it could be a GUID. Obvious?
No. Strongly typed? Sure, buried down the MSIL. But the only way we would be
able to find out what we're dealing with is if you actually dig into the
MSIL or open up the database designer or, more likely, SQL Server Management
Studio, and examine the design of the database table. Suddenly LINQ ain't so
time-saving.

What LINQ should have done is have strongly typed SQL statements rather than
infer the crap out of everything based on a remote database schema. Visual
Studio should have auto-generated some strongly-typed code based on a select
at design-time. You could have been just as lazy, but far more verbose.
Terseness getting severely overrated right now; I'm obviously speaking in
favor of verbosity.

Try "var" in another language. "Boo" for duck typing--I think Boo is a great
language. But don't corrupt C# with this insolent laziness.

"var" is an evil beast that will take an otherwise wonderful language and
make horrible programmers out of people. It will cause C# to be exactly what
VB.NET already is -- a strongly-typed language that is very powerful but
that is used by undisciplined people who are too lazy and undisciplined, or
most often just plain too ignorant, to know how to write well-defined,
clearly readable, well-designed, easily maintainable code.

If only it wasn't too late. The tsunami is coming. But our engineering team
will NOT take the plunge into C# 3.0.

Jon

 

[Nicholas Paldino [.NET/C# MVP]]

Not to marginalize your post, but your last statement pretty much axes
all the effort you put into it:

If only it wasn't too late. The tsunami is coming. But our engineering team
will NOT take the plunge into C# 3.0.

If you don't like it, don't use it, end of story. Outside of how you
use it, and the engineering team that you work with uses it, what do you
care if someone else uses it? It's not going to break any of the code you
have now, so that's a non-issue. Your coding standards are going to dictate
what you can use and how you name your variables, and your ecosystem will be
preserved.

The only thing I think that Bill is wrong on is that in the example that
selects strings from an array of strings, it should be assigned to
IEnumerable<string>. I agree, var shouldn't be used in cases where you know
the type, and in this case, you do know the type that is being returned.
However, in order to get projections to work, there is no way around var.

Granted, having VS.NET wire up the code for you in known types will be
nice (and it should do something like this, converting projections/anonymous
types to known-types), but the amount of code you would have to write by
hand if you didn't have VS is enormous, and they can't depend on the IDE to
pick up where language features fail.

I agree that those that use var when they know the type of what is being
used (and yes, even in the case of those long generic types, use the using
directive to alias it instead) should be skewered, but really, it's not that
bad.

It's also Friday, I'd save this kind of rhetoric-filled post for Monday.
That's what Monday's are for.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Bill Wagner posted something here ..

http://msdn2.microsoft.com/en-us/vcsharp/default.aspx

"Local Type Inference, Anonymous Types, and var"
"Of all the features in C# 3.0, local type inference is generating the
most questions and misunderstanding. You know, 'var'. The fact is local
type inference is not as scary as it seems. In fact, you're not losing
strong typing. It's a simple time saver that is actually necessary to
support anonymous types."

Great. I appreciate that it's "necessary" to support LINQ (and LINQ is the
only major reason why it's necessary to support anonymous types).

Well then I guess my issue is with anonymous types. But I dislike var. It
is stinky to my nostrils. Bill can argue till the cows come home that it's
still strongly typed and produces MSIL that is no different than C# 2.0
code. I don't care, it's not the MSIL that I have to stare at all day
long.

It was only a couple years ago that I was running around singing the
praises of Microsoft and celebrating the wonderous, magical LINQ invention
(back then it was a Microsoft Research invention, C-Omega). Finally, SQL
and C# would be beautifully merged syntactically. So don't get me wrong, I
understand and appreciate LINQ's value.

But I also understand and appreciate the hell I went through, and why I am
so glad I went through it, to wean myself off of Visual Basic 6.0
(Variant-land) and javascript and vbscript, and into Java and C#. In gross
celebration of lessons learned, I hacked together a silly Variant object
for C#, just for fun.
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=2854

It didn't take long that I began really appreciating strongly typed
declarations. It had nothing to do with performance. It had little to do
with stability. It had mostly to do with the fact that as I'm scrolling up
and down in my code, or when I right-click a variable and choose "Go To
Definition", I immediately saw what the heck it was. Not what it was
named. Not what was assigned to it. But what it was.

So var produces strongly-typed MSIL. Great. But it's still anonymous.

Introducing var forces us to revert back to the old Hungarian notation
style naming conventions--that is, variables will have to have their types
inferred in the name. Yes, the type is strongly typed at compile-time. And
if Microsoft builds Visual Studio right, yes, IntelliSense tooltips will
reveal what type a variable is. But what if we don't want to hover over
the variable with the mouse? What if we're not using Visual Studio? When
editing code, if you have to do extra work of any sort to discover the
type of a variable, productivity is lost.

The biggest grief of var is that it's really only useful for LINQ+SQL, but
it will compel Variant-style VB coders and javascript script kiddies to
dilute the somewhat more disciplined structure of C# for no good reason.
Normal declarations that do not involve LINQ and could do just as well
with a standard type reference will use var instead....

var doc1 = myComplexObject.GetDoc();
// oh, by the way, GetDoc() returns a System.Xml.XmlDocument

var doc2 = myOtherObject.GetDoc();
// oh, and um, GetDoc() returns a System.Windows.Forms.HtmlDocument

What's wrong with this picture? I'll tell you what's wrong: "var" sucks!!
There is nothing here that makes what doc1 and what doc2 are. The method
names of each object aren't necessarily wrong. But now they'd have to be
renamed to expose the type of data being returned. Where is the advantage?

Bill makes the lousy argument:
<quote>
string[] words = { "cherry", "apple", "blueberry" };

var sortedWords =
from w in words
orderby w
select w;

It's fairly obvious that sortedWords is some sequence of strings. (It's
actually a System.Query.OrderedSequence<string, string>). In my opinion,
OrderedSequence<string,string> doesn't add any new information for me when
I'm trying to read this code. In fact, I think it's clearer with the var
keyword.
</quote>

No, Bill, when you hide the declaration of the "words" variable, it is not
obvious that sortedWords is some sequence of strings. What if a Words was
an array of a complex type called Word? And why are you limiting yourself
to words in these samples? How often do we have the luxury of working with
objects that are "obviously" composed of strings or arrays or collections
thereof?

Most often, types consist of all kinds of weird values. Even when pounding
against a SQL database table, a particular table could have an ID column
that could be an integer, it could be a string, it could be a GUID.
Obvious? No. Strongly typed? Sure, buried down the MSIL. But the only way
we would be able to find out what we're dealing with is if you actually
dig into the MSIL or open up the database designer or, more likely, SQL
Server Management Studio, and examine the design of the database table.
Suddenly LINQ ain't so time-saving.

What LINQ should have done is have strongly typed SQL statements rather
than infer the crap out of everything based on a remote database schema.
Visual Studio should have auto-generated some strongly-typed code based on
a select at design-time. You could have been just as lazy, but far more
verbose. Terseness getting severely overrated right now; I'm obviously
speaking in favor of verbosity.

Try "var" in another language. "Boo" for duck typing--I think Boo is a
great language. But don't corrupt C# with this insolent laziness.

"var" is an evil beast that will take an otherwise wonderful language and
make horrible programmers out of people. It will cause C# to be exactly
what VB.NET already is -- a strongly-typed language that is very powerful
but that is used by undisciplined people who are too lazy and
undisciplined, or most often just plain too ignorant, to know how to write
well-defined, clearly readable, well-designed, easily maintainable code.

If only it wasn't too late. The tsunami is coming. But our engineering
team will NOT take the plunge into C# 3.0.

Jon

 

[Jon Davis]

Not to marginalize your post, but your last statement pretty much axes
all the effort you put into it:

If only it wasn't too late. The tsunami is coming. But our engineering
team will NOT take the plunge into C# 3.0.

If you don't like it, don't use it, end of story.

While I won't, the basis of my frustration was the other coders--not myself.
I know how to write good code. It's having to support the output of coders
who code as if they just learned VBScript that is bothering me.

Outside of how you use it, and the engineering team that you work with
uses it, what do you care if someone else uses it?

Because "it" very quickly dwindles into a proprietary standard.

It's not going to break any of the code you have now, so that's a
non-issue.

Thank God. But I still hate var.

Your coding standards are going to dictate what you can use and how you
name your variables, and your ecosystem will be preserved.

Yes, *my* coding standards. *Our* coding standards. But by our being forced
to stick with v2.0 in order to avoid var,

a) our team would be forced to withhold ourselves from taking advantage of
other 3.0 features than what var uses,

b) I personally, and the other engineers on our team, would be presented
with an unpredicted and undesirable dillemma of whether to offer engineering
services, whether to the public or to an employer, as a C# 2.0 purist or as
a C# 3.0 cutting edge Microsoftie who drinks all the kool aid that gushes
out of the fountains of Redmond and participates in the very bandwagon that
will ultimately make a mess of the output of C# coders everywhere, and

c) put in context, the point was, add us to the list of people who don't
subscribe to the appreciation of 'var'. "Don't like it, don't use it,"
phooey, what are you doing here? I'm here to discuss this sort of
stuff--even if in a monologuish soapbox stance.

However, in order to get projections to work, there is no way around var.

Yes. There is. Auto-generate the inferred type information directly in the
code rather than at compile time. Actually, you and others talk as if
projections were a necessity in themselves. What I'm getting at is, if 'var'
is the necessity of a new feature, my hatred of 'var' is greater than that
feature. I loved the LINQ idea, but that was when I heard about C-Omega as
C#-based language, not as C# v3, supposed successor to the language I work
with everyday.

Granted, having VS.NET wire up the code for you in known types will be
nice (and it should do something like this, converting
projections/anonymous types to known-types), but the amount of code you
would have to write by hand if you didn't have VS is enormous, and they
can't depend on the IDE to pick up where language features fail.

That doesn't make sense to me. I see var as the failure. But at least we
agree that VS should try to auto-populate "var" with known types.

I agree that those that use var when they know the type of what is
being used (and yes, even in the case of those long generic types, use the
using directive to alias it instead) should be skewered, but really, it's
not that bad.

Not that bad? I spend half my coding time already pulling my hair out
looking at other people's lazily written or generated code--XML node or
Control lookups that should have been referenced by name or ID are instead
referenced by index, referenced ASP.NET control names plopped in with
namespace of "uc1" rather than origin, variable names as numbered type names
rather than purpose, little "thorn in the side" things that make my job one
minor bit less enjoyable. And now 'var'? Ugh.

It's also Friday, I'd save this kind of rhetoric-filled post for
Monday. That's what Monday's are for.

LOL .. well we differ here I use the weekends to zoom out and ask myself
questions like what the heck am I doing it all for.

....

 

[Chris Nahr]

I'm pretty sure I've never seen a more hilarious overreaction to a
tiny new feature, and I've been reading programming newsgroups for a
long time...

 

[Jon Davis]

I'm pretty sure I've never seen a more hilarious overreaction to a
tiny new feature, and I've been reading programming newsgroups for a
long time...

The sky is falling!!

Jon

 

[OD]

What you're saying about 'var' is not false, there is a risk to see C#
code becoming like interpreted msbasic of the 70's ..
But LINQ is a so big progress, really fantastic, that perhaps, the wise
developer will only use 'var' in this context.
Bill will not come in your back when you're coding to force you using
'var', do as you feel

 

[Alun Harford]

While I won't, the basis of my frustration was the other coders--not
myself. I know how to write good code. It's having to support the output
of coders who code as if they just learned VBScript that is bothering me.

People who can't write decent code for toffee will write bad code with
or without var. Just remember two rules:
1) If you have such programmers on your team, they need 'moving into a
different role' (ie. moving far away from you).
2) Don't buy code written by idiots.

If, for some reason, you break one of those two rules, I'm sure the fact
that they used var all over the place will be the least of your
worries... (particularly since it'll be easy to make, or download, a
tool to parse the C# and convert all those vars into 'properly' typed
variables)

Alun Harford

 

[Nicholas Paldino [.NET/C# MVP]]

Jon,

See inline:

a) our team would be forced to withhold ourselves from taking advantage of
other 3.0 features than what var uses,

No, you won't. You can eschew var, as well as extension methods, and
the syntax that translates queries from the C# 3.0 language and actually
chain the static method calls yourself, passing anonymous delegates and
known types as the return. Granted, it is going to be a ROYAL PITA but it
^IS^ possible.

b) I personally, and the other engineers on our team, would be presented
with an unpredicted and undesirable dillemma of whether to offer
engineering services, whether to the public or to an employer, as a C# 2.0
purist or as a C# 3.0 cutting edge Microsoftie who drinks all the kool aid
that gushes out of the fountains of Redmond and participates in the very
bandwagon that will ultimately make a mess of the output of C# coders
everywhere, and

Well, welcome to the wonderful world of software engineering. "It ain't
just static" should be the motto. That's just the nature of the beast.
There are ALWAYS going to be new technologies that are coming out and you,
being a professional in the field, will have to decide on how you want to
leverage those technologies in what you do to provide for how you make a
living. You aren't the first person to have to face this, and you won't be
the last.

c) put in context, the point was, add us to the list of people who don't
subscribe to the appreciation of 'var'. "Don't like it, don't use it,"
phooey, what are you doing here? I'm here to discuss this sort of
stuff--even if in a monologuish soapbox stance.

I was trying to respond to what was a predominantly rhetoric-filled
post. Granted, you have some very valid, and very good points, some of
which I agree with (VS being able to generate known types) and some which I
don't agree with (var is evil). However, the rhetoric gets in the way

Yes. There is. Auto-generate the inferred type information directly in the
code rather than at compile time. Actually, you and others talk as if
projections were a necessity in themselves. What I'm getting at is, if
'var' is the necessity of a new feature, my hatred of 'var' is greater
than that feature. I loved the LINQ idea, but that was when I heard about
C-Omega as C#-based language, not as C# v3, supposed successor to the
language I work with everyday.

Doing work with SQL, you realize that projections become necessary VERY
quickly. Ok, I don't want to be absolute. COULD you get away without
having them, yes, absolutely, but again, ROYAL PITA. I'm not against doing
something that takes a lot of work because it is the right thing to do, but
LINQ here is trying to bridge that gap between the relational and procedural
models. The relational model (as represented by the implementation of the
SQL standard across many database products) depends heavily on projections.
It's something that they probably feel they couldn't leave out.

Now, I agree, I do hope, and expect, quite frankly, that VS.NET will be
able to take your anonymous types and make known types. If it has that
facility, then you can still code in your 2.0 style, and pass back
IEnumerable<known type> as the return values of the calls to the LINQ
library functions (you might have to cave and use the assignment feature in
C# 3.0 though).

However, this is what I meant by you shouldn't depend on tools to fill
in the gap where the language fails. You can't expect that everyone will
have VS.NET installed. Hell, I've written code in notepad before, others
write code in Eclipse, someone is writing C# code in Emacs as well. Those
tools can not be depended on to support the feature.

Not that bad? I spend half my coding time already pulling my hair out
looking at other people's lazily written or generated code--XML node or
Control lookups that should have been referenced by name or ID are instead
referenced by index, referenced ASP.NET control names plopped in with
namespace of "uc1" rather than origin, variable names as numbered type
names rather than purpose, little "thorn in the side" things that make my
job one minor bit less enjoyable. And now 'var'? Ugh.

You see the potential for abuse here because of the ways that other
technologies have been abused in the past by people that don't have an
understanding of those technologies.

I get that, completely. I respect it tremendously.

There are always going to be people who don't know what the best way to
do things are. The ones that do it out of ignorance which they choose to
perpetuate are never going to advance in this field, while the ones that are
not ignorant are going to learn and perpetuate (hopefully) best practices.

If the case where that as a society we restricted all growth and
innovation because of the potential for abuse of those innovations, then we
would still be living in caves without fire.

So this leads to what I think you and your team should do in respects to
C# 3.0. Don't give up on it, and certainly don't throw it away. You are
throwing away a HUGE amount of benefit for one simple language feature which
you don't like, don't have to use, and can get around and still gain the
benefits of.

For example, say you had your class:

public class Customer
{
public string Name;
public int Age;
public string Address;
}

And you wanted a query that returns just the name and age. Well,
hopefully the tooling will support it (from anonymous types), and if it
doesn't, you can always code by hand, the following:

// Ok, the naming here is abhorrent, but that's not the point.
public class PartialCustomer_Name_Age
{
public string Name;
public int Age
}

And then you can perform your query on an IEnumerable<Customer>
implementation (like an array) like this:

IEnumerable<PartialCustomer_Name_Age> query =
from c in customers
select new PartialCustomer_Name_Age(){ Name = c.Name, Age = c.Age };

No var at all!

LOL .. well we differ here I use the weekends to zoom out and ask
myself questions like what the heck am I doing it all for.

Money? You like it? The women?

While I am making light of it, I do hate the idea of seeing someone in
this profession asking these questions because of something they don't like,
when there is so much more about this field which can be enjoyed.

Kind of like anything else. =) Enjoy the weekend.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I agree that there is a possibility to misuse the var keyword, and I
have no doubt that some people will, but I don't think that there is any
reason to fear that we will move into the medeval times of programming
that you describe.

As comparison, you can look at the VB.NET language. There you don't even
have to declare the variables if you don't want to, and you can mix data
types back and forth to produce monstrosities like:

a = "35"
a = a + 7

(What is the result? 42, "42", 357 or "357"? That's not exactly obvious.)

Still, there is very little VB.NET code that actually look like this,
simply beacuse almost everyone knows that you can't write good code this
way.

Similarly, it should not be a big problem to educate people of the
proper use of the var keyword.

 

[Jon Davis]

Nicholas,

Bravo. Yours is the kind of response I highly admire and respect. You don't
patronize nor insult me. You examine what I have to say, not who I am or how
well I'm doing (although the "welcome to the world of software development"
comment was a little presumptuous of a lack of experience with the industry,
but I'll take it tongue-in-cheek). And your response went well beyond the
level of appreciable merit than my light-hearted melodrama (which was
sincere nonetheless).

I'll take your thoughts to heart.

Thanks,
Jon

 

[Jon Davis]

People who can't write decent code for toffee will write bad code with or
without var. Just remember two rules:
1) If you have such programmers on your team, they need 'moving into a
different role' (ie. moving far away from you).
2) Don't buy code written by idiots.

That's not fair, to them. There are some incredibly mindblowingly-brilliant
people who are so left-brained that you'd almost think there was something
"wrong" with them. Very gifted folks. Senior architect folks. They don't
care one shizzly-dizzle (I think I made that up! ) about writing elegant
code. Their interests are solely "is it performant?" or "can I get this done
fast so I can get back to work on other matters, like crunching a billion
database records for data mining, or integrate with our custom-built
indexing service?" Judging someone by their coding style, particularly when
they are so senior, is not productive.

One of the key responsibilities of those maintaining the C# language,
whether Microsoft or ECMA, is to strive to retain its built-in imposition of
a certain degree of elegance and maintainability inherent in its syntax.
Enabling "var" is like passing out guns for people to shoot themselves and
each other with. Of course, you can argue forever that guns are safe if you
know how to use them and if you choose to work with people who know how to
use them well. But that doesn't change the fact that guns are inherently
unsafe.

Granted, the "gun" metaphor only works here if observed against a paintgun,
not a P-90. I realize that "var" does not inherently break code even if
abused, at least not without stopping at compilation. Even so, passing out
such "toys" to the general public is inherently a bad idea, I think.

Jon

 

[Jon Davis]

(particularly since it'll be easy to make, or download, a tool to parse
the C# and convert all those vars into 'properly' typed variables)

That's a good idea. Again I really hope VS does this for us, even if
optionally!! But if not I'll be watching for any third-party plug-ins that
do it. I might do it myself as I've played with the Visual Studio
extensibility bits but I'm hoping someone else will.

Jon

 

[Jon Skeet [C# MVP]]

That's not fair, to them. There are some incredibly mindblowingly-brilliant
people who are so left-brained that you'd almost think there was something
"wrong" with them. Very gifted folks. Senior architect folks. They don't
care one shizzly-dizzle (I think I made that up! ) about writing elegant
code. Their interests are solely "is it performant?" or "can I get this done
fast so I can get back to work on other matters, like crunching a billion
database records for data mining, or integrate with our custom-built
indexing service?" Judging someone by their coding style, particularly when
they are so senior, is not productive.

I disagree - because code very rarely stays as it's first written
forever, and if no-one can understand the code when it needs to be
maintained, its value is *hugely* diminished.

Perhaps calling them idiots is unfair, but I'd still rather have
someone who can only get half as much done, but get it done in a
maintainable way. Unless you're writing throw-away code in the first
place, of course, in which case, who cares?

One of the key responsibilities of those maintaining the C# language,
whether Microsoft or ECMA, is to strive to retain its built-in imposition of
a certain degree of elegance and maintainability inherent in its syntax.
Enabling "var" is like passing out guns for people to shoot themselves and
each other with. Of course, you can argue forever that guns are safe if you
know how to use them and if you choose to work with people who know how to
use them well. But that doesn't change the fact that guns are inherently
unsafe.

Granted, the "gun" metaphor only works here if observed against a paintgun,
not a P-90. I realize that "var" does not inherently break code even if
abused, at least not without stopping at compilation. Even so, passing out
such "toys" to the general public is inherently a bad idea, I think.

Sure - and I'd agree, if the benefit weren't so tangible. If "var" had
been introduced for no purpose other than to let people declare
variables without specifying the type, I'd be completely with you. I
just feel the benefits outweigh the potential costs. It's not hard to
spot abuse of var in a code review and do your best to prevent it.

It's not in the same league of potential abuse as, say, macros or
variants, for instance - although people still bemoan the lack of the
former

 

[Nicholas Paldino [.NET/C# MVP]]

Jon,

Admittedly, I didn't think that you didn't have experience. It was
meant to be humorous. I mean "it ain't just static". I give you gold I
tell you, gold! =)

Thank you for the response. It's something I appreciate a great deal.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas,

Bravo. Yours is the kind of response I highly admire and respect. You
don't patronize nor insult me. You examine what I have to say, not who I
am or how well I'm doing (although the "welcome to the world of software
development" comment was a little presumptuous of a lack of experience
with the industry, but I'll take it tongue-in-cheek). And your response
went well beyond the level of appreciable merit than my light-hearted
melodrama (which was sincere nonetheless).

I'll take your thoughts to heart.

Thanks,
Jon

 

[Martin Carpella]

But LINQ is a so big progress, really fantastic, that perhaps, the wise
developer will only use 'var' in this context.

While being a fan of strongly typed expressions (and verbose
expressions, so I don't need any tool for identifiying the strong type),
I see other valid uses regarding "var": if you have to instantiate
something of a veryl long-named class, it can really safe you typing
without losing verboseness, e.g.

var x = new AVeryVeryVeryLongClassName();

is in my opinion more readable than

AVeryVeryVeryLongClassName x = new AVeryVeryVeryLongClassName();

Of course, like with any other tool, its just a matter of discipline and
experience of the developer, how the new tool is being used.

Best regards,
Martin

 

[Ravichandran J.V.]

If you consider the *var* as the first example of an inferred type maybe
you would find it easier to accept it.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com