Anyone else trying to keep up with all the newish .NET stuff?

[d000hg]

From that diagram I stopped following around 3.0... lambdas and LINQ can be very useful but I don't really like var and everything later is gibberish to me.

[eek]

From that diagram I stopped following around 3.0... lambdas and LINQ can be very useful but I don't really like var and everything later is gibberish to me.

var is useful in a its usually x but occassionally could be y department.

likewise optional parameters just keep the code a bit neater you don't end up with 5 functions for variations of input.

[tranceporter]

I use implicit var and linq/lambdas all the time. Rest of the gibberish, I wash my hands of it

[d000hg]

var is useful in a its usually x but occassionally could be y department.

Isn't that what interfaces are for?

likewise optional parameters just keep the code a bit neater you don't end up with 5 functions for variations of input.

I suppose in C++ we already had part of that with default parameters, which never seemed to take on elsewhere. Though it wasn't a very elegant implementation... named+optional parameters I can see making sense.

[eek]

Isn't that what interfaces are for?

I suppose in C++ we already had part of that with default parameters, which never seemed to take on elsewhere. Though it wasn't a very elegant implementation... named+optional parameters I can see making sense.

var goes hand in hand with linq. It solves the issue where linq returns something that the programmer wasn't expecting.

[d000hg]

If it returns something I wasn't expecting, I'd rather know about it than have things merrily go on doing something I hadn't planned on!

[Jaws]

var goes hand in hand with linq. It solves the issue where linq returns something that the programmer wasn't expecting.

I think you might have misunderstood that.

"var" was put there to handle anonymous types - as a programmer you should know what those look like because they are limited to the body of a method. If you want one of those to escape your method (outside of closures) you're just dealing with the "object" type again and are going to need to use reflection to get at its properties.

I use "var" all the time too, do not see the need to mention the type twice when you're creating an object. I'm a bit more explicit with declarations when something is being returned from a method however.

When you declare a variable with "var" you cant just change its type like you can with a dynamic language - it's fixed due to C#'s static typing.

[DimPrawn]

I think you might have misunderstood that.

"var" was put there to handle anonymous types - as a programmer you should know what those look like because they are limited to the body of a method. If you want one of those to escape your method (outside of closures) you're just dealing with the "object" type again and are going to need to use reflection to get at its properties.

I use "var" all the time too, do not see the need to mention the type twice when you're creating an object. I'm a bit more explicit with declarations when something is being returned from a method however.

When you declare a variable with "var" you cant just change its type like you can with a dynamic language - it's fixed due to C#'s static typing.

Yes. To me, var means "I'm a lazy bugger. The compiler knows the type, the VS.NET knows the type, so why should I bother typing it in?"

[DimPrawn]

Another gem seen in some code today.

if (Enumerable.Range(0,100).Contains(x)) { // do stuff }

Checking if x >= 0 and <=100