|
Unruled Boy wrote: it's a lot more difficult to read the code.
More difficult to read or understand?
IJunk awesomeJunk = new AwesomeJunk ();
vs
var awesomeJunk = new AwesomeJunk ();
I really don't see much of a difference..?
Todd Smith
|
|
|
|
|
Those aren't equivalent are they? 
|
|
|
|
|
PIEBALDconsult wrote: Those aren't equivalent are they?
yes....
Todd Smith
|
|
|
|
|
But in the first one it says IJunk, not AwesomeJunk; won't var make it AwesomeJunk instead?
|
|
|
|
|
This is typically the case when you won't use var because you want to use your AwesomeJunk as an IJunk but var will make it an AwesomeJunk.
|
|
|
|
|
Gtrwld wrote: This is typically the case when you won't use var because you want to use your AwesomeJunk as an IJunk but var will make it an AwesomeJunk.
So you just cast it if you need an IJunk.
The assumption here is public class AwesomeJunk : IJunk
It's very handy when writing things like linq extension methods.
Todd Smith
|
|
|
|
|
I agree, this is an addition to the language similar to goto. It is only meant for people which hack small programs on their own in small office environments. In real environments I do not see why I would use it, but I am open to good suggestions 
One of the arguments I read in favor of using var was that code was easier to reuse ... Use generics instead !
|
|
|
|
|
I find that var makes refactoring easier in some scenarios. For example, when the return type of a method changes (from a class type to say an interface) and var has been used to hold the returned value, one doesn't need to update consuming code.
There is no doubt, however, that it does make code harder to read.
|
|
|
|
|
are you sure?
SomeMyClassWithBigNameCollection<sometype1, sometype2=""> theVariableName = new SomeMyClassWithBigNameCollection<sometype1, sometype2="">(params);
vs
var theVariableName = new SomeMyClassWithBigNameCollection<sometype1, sometype2="">(params);
beauty is relative thing...
|
|
|
|
|
|
|
You haven't run out of cake have you?
|
|
|
|
|
I'll have the fish..... tastes of human sir.
|
|
|
|
|
The cake is a lie!
Proudly drinking the finest Maryland craft beer. Visiting Maryland for business? First round is on me!
|
|
|
|
|
It's a delusion, snare to trap the unwary, blot on the landscape etc. When I declare a variable I want to know what type it is, and I want to know why I cast it that way.
|
|
|
|
|
I'm still unsure about this. I have read about this in the "More Effective C#" book, but I'm not sure whether I agree with everything that is said. The only benefit I can see is that there is less code to type, and potentially less to change if you change a data type. I'm not sure that it makes the code more readable though. At the moment I use it often, but I'm having doubts about whether I should be using it.
|
|
|
|
|
The benefits are that you can work with anonymous types. It's pretty obvious. When it comes to using Linq you can create result-sets with just the values you want, rather than an entire entity:
<br />
var list = from person in db.Person<br />
where person.Dob < DateTime.Now.AddYears(-18)<br />
select new<br />
{<br />
person.PersonId,<br />
person.Name,<br />
person.Surname<br />
};<br />
Which will clearly make queries faster, and communication to SQL quicker (less data to bring back).
Once you have an anonymous type returned from a query, then iterating it thus makes sense:
<br />
foreach(var item in list)<br />
{<br />
Console.WriteLine(item.Name);<br />
Console.WriteLine(item.Surname);<br />
}<br />
Vars are local to the method's scope anyway, so if you don't know what the variable is then your method is far too complex and you should refactor.
I'm all for them. The 'dynamic' type coming in C# 4.0 is the one to worry about. That should in my opinion only be used for communication to non-typesafe resources (like COM, Javascript etc), and maybe used for dynamic fixup of events, methods and properties in things like ASP.NET, but that's all really.
|
|
|
|
|
Right, var is only for use with Linq. But you shouldn't use Linq either.
|
|
|
|
|
It isn't only used for Linq. It's useful for anonymous types, and if you so chose, to cut down on typing (I personally don't chose this, but there's nothing fundamentally wrong with it).
And why shouldn't you use Linq? A strongly typed method of interogating data-stores. Seems a pretty good idea to me. Also with the many-core world upon us, having features integrated into the language which can automatically parallelise is a no brainer.
|
|
|
|
|
OMG not use LINQ??? in which world are you living in? of course you have not ever used Entity Framework or .NET RIA Services, lol I feel pitty for the people out there that still uses SPs or similar old approaches for data management
|
|
|
|
|
NHibernate?
Proudly drinking the finest Maryland craft beer. Visiting Maryland for business? First round is on me!
|
|
|
|
|
chaosgeorge wrote: that still uses SPs
Linq works with stored procedures, doesn't it? (I don't use either.)
I feel pity for any who jump on the latest bandwagon. The old bandwagon is time-tested, tried and true.
|
|
|
|
|
Not really SPs are something and LINQ another although both are SQL at the end, and you can use SPs in LINQ too, the old bandwagon lacks of too many things addresed by new technologies, a lot of the mistakes committed by old bandwagons can be solved now with technologies like LINQ, I don't think your programming experience is any better with SPs than with LINQ
|
|
|
|
|
And yet Linq is just a layer atop ADO.net; I cut out the middleman and retain control.
|
|
|
|
|
So you're referring to LINQ to SQL or LINQ to Entities. But there's LINQ to Objects, LINQ to XML which are definitely valuable whatever you may think of the former.
Kevin
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
