The new GOTO Statement?

[CPallini]

I disagree. :)

Veni, vidi, vici.

[OriginalGriff]

It's easier to type - but it doesn't make the code more readable! You have to check the type of the IEnumerable that the variable is declared from in order to find out what type you are using within the loop:

foreach (var v in MyClass.Items)
{
...
}

Or

foreach (KeyValuePair<Guid, List<string>> kvp in MyClass.Items)
{
...
{

(Not that I'm advocating using KeyValuePair<Guid, List<string>> directly anyway, you understand)

Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water

[BobJanova]

I quite like the use of 'var' when the thing to the right is clearly typed, e.g.

var map = new Dictionary<string, int>();

It was rather a failing in all C family languages that you had to write the type twice before when it's clearly there in the initialiser, and using var here is not hiding anything. I don't actually like it in Linq, it's too hard to see by inspection what the type of a Linq expression is. I quite like declaring those as IQueryable<whatever>.

[Lost User]

Well it doesn't really go that far, but the case statements don't define any sort of block (they behave much the same way as labels) and (as long as it's somewhere in a switch) you can mix them with other control flow. For example, Duff's device[^], which mixes a switch and a do/while.

[BobJanova]

compare is nothing more or less than a local method; this example is no less readable than the boring alternative:

public string ReturnSomething()
{
// ... some logic
// ...

        // some more logic flow
        // ....

        if (compare("a", "b", "c", "d")) {
            // some logic
        }

        return "Something";
    }

private boolean compare(string compare1, string compare2, string compare3, string compare4) {
return (compare1.Equals(compare2, StringComparison.InvariantCultureIgnoreCase) &&
compare3.Equals(compare4, StringComparison.InvariantCultureIgnoreCase));
}

... and arguably more so, if the method is only used in one place, because you're not gumming up the class scope with methods that are not relevant to any of it apart from one function. compare cannot affect the control flow of the containing function, it is a normal function which takes arguments and returns a result – it is just declared as a dynamic Func type for technical reasons. Delphi allows you to declare local methods statically for exactly this kind of situation, and (like so much in Delphi) that is a really good idea.

[Steve 2]

haha sounds like me. var is certainly not only nice for foreach loops or LINQ. I find it rather stupid to type something like:

Dictionary>> stuff = /*sigh*/ new Dictionary>>();

Yes, stupid indeed. And it's exactly that type of scenario the "var" keyword was made for.

[ekolis]

Hmm, come to think of it, I recently discovered that in C#, you can declare a variable in one case block and use it in a subsequent case block!

[Fabio Franco]

OriginalGriff wrote:

var should be banned outside Linq!

There should be a compiler warning for using var anywhere else. The thing that bothers me the most is to read code that the lazy programmer put var everywhere. It is one of those language features that I really question whether it came for bad or for good. It's too much abused, specially by beginners that don't understand the porpose of var. In my opinion var should only be used to infer anonymous types and nothing else.

To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

[PIEBALDconsult]

Steve#2 wrote:

type of scenario the "var" keyword was made for.

Bullpuckey; it was made for Linq. That's exactly the scenario the using directive was made for:

using MyDic = Dictionary<int, List<Vec3<float>>> ;
...
MyDic stuff = new MyDic() ;

(Except that generics cme later. :sigh: )

[Fabio Franco]

Steve#2 wrote:

And it's exactly that type of scenario the "var" keyword was made for.

You're either joking or don't understand the purpose of var.

To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

[Fabio Franco]

sisnaz wrote:

He says it's because it makes it loosely coupled

:doh:

To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

[PIEBALDconsult]

BobJanova wrote:

it's too hard to see by inspection what the type of a Linq expression is

And that's why var was created -- for times when you can't know the type when writing the code.

[Fabio Franco]

PIEBALDconsult wrote:

Bullpuckey; it was made for Linq.

I'd just like to add that it was made for Linq because Linq generates a lot of anonymous types. It would be a hell to create classes for all possible result sets.

PIEBALDconsult wrote:

That's exactly the scenario the using directive was made for:

using MyDic = Dictionary<int, List<Vec3<float>>> ;
...
MyDic stuff = new MyDic() ;

(Except that generics cme later. :sigh: )

Yeah, I'd say nothing was made for that so we do workarounds :) Or we could model our own classes that handle trickier business rules, I like to believe everyone is capable of that.

To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia

[PIEBALDconsult]

OriginalGriff wrote:

It's easier to type - but it doesn't make the code more readable!

Hear hear! That's what so many developers don't seem to realize -- less typing tends toward less readable code. It's what I think is worst about the Unix crowd -- the idea that fewer keystrokes saves time. A stitch in time saves nine -- writing everything in detail up front saves time and effort down the road.

using GuidStringPair = KeyValuePair<Guid, List<string>>
...
foreach (GuidStringPair kvp in MyClass.Items)
{
...
{

[OriginalGriff]

Absolutely! Overuse smacks of being too lazy to think about your datatypes, and is far too reminiscent of VB's Dim for my taste.

Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water

[Steve 2]

I don't think it was made just for LINQ, that's not what I've read in countless introdution texts about new features back then. What do you mean by "Except that generics cme later" ? Generics are there since .NET 2.0, var since 3.5 IIRC.

[Steve 2]

I think I do: automatic type inference. Which is what my example used them for.

[Steve 2]

ah, you mean the using ^^ Haven't seen this usage of it, wow, yet another meaning of the keyword "using", I think now that's quite an abuse... (language design wise)

[aojepojefpoejafpeoj]

And you have to type all that in C# for what reason? You have autocomplete, can't complain about having to type too much.

[Steve 2]

[quote]I'd just like to add that it was made for Linq because Linq generates a lot of anonymous types. It would be a hell to create classes for all possible result sets.[/quote] Sounds like it makes sense. But "was made because of LINQ" sounds then more accurate than "made *for* LINQ", since automatic type inference is surely useful in other contexts.