The new GOTO Statement?
-
Yes, I agree. Every element of a language has it's use - even
gotoandvarin C#- it's just that if you use them inappropriately you get less readable code instead of more. Personally, I find lambdas are useful in their place, but I avoid using them most of the time.varshould be banned outside Linq!Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
varshould be banned outside Linq!There should be a compiler warning for using
varanywhere else. The thing that bothers me the most is to read code that the lazy programmer putvareverywhere. 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 ofvar. In my opinionvarshould 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
-
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.
Steve#2 wrote:
type of scenario the "var" keyword was made for.
Bullpuckey; it was made for Linq. That's exactly the scenario the
usingdirective was made for:using MyDic = Dictionary<int, List<Vec3<float>>> ;
...
MyDic stuff = new MyDic() ;(Except that generics cme later. :sigh: )
-
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.
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
-
YES! I completely agree. I have a team member that declares EVERYTHING as var. He says it's because it makes it loosely coupled and also C Sharpner tells him too.
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
-
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>.
BobJanova wrote:
it's too hard to see by inspection what the type of a Linq expression is
And that's why
varwas created -- for times when you can't know the type when writing the code. -
Steve#2 wrote:
type of scenario the "var" keyword was made for.
Bullpuckey; it was made for Linq. That's exactly the scenario the
usingdirective was made for:using MyDic = Dictionary<int, List<Vec3<float>>> ;
...
MyDic stuff = new MyDic() ;(Except that generics cme later. :sigh: )
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
usingdirective 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
-
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
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 wrote:
varshould be banned outside Linq!There should be a compiler warning for using
varanywhere else. The thing that bothers me the most is to read code that the lazy programmer putvareverywhere. 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 ofvar. In my opinionvarshould 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
Absolutely! Overuse smacks of being too lazy to think about your datatypes, and is far too reminiscent of VB's
Dimfor my taste.Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Steve#2 wrote:
type of scenario the "var" keyword was made for.
Bullpuckey; it was made for Linq. That's exactly the scenario the
usingdirective was made for:using MyDic = Dictionary<int, List<Vec3<float>>> ;
...
MyDic stuff = new MyDic() ;(Except that generics cme later. :sigh: )
-
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
-
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
usingdirective 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
-
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.
And you have to type all that in C# for what reason? You have autocomplete, can't complain about having to type too much.
-
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
usingdirective 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
[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.
-
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
It just seems redundant to me, the dictionary's type should already be known and the key value pair will always have the same types. I don't feel much clarity is lost there, but then again when I use it, it's in code I wrote so hopefully I have a clear understanding to begin with (not always the case of course...).
-
And you have to type all that in C# for what reason? You have autocomplete, can't complain about having to type too much.
sure autocomplete... it's still shorter than that, and actually I don't want to *read* all that much redundancy in a line of code, it's just plain idiotic to mention the type twice when the compiler knows anyway. Actually this is a thing I always hated about C and C++, because it seemed stupid, that I had to repeat myself although the damn compiler *should know* by assignment when creating a variable.
-
OriginalGriff wrote:
varshould be banned outside Linq!There should be a compiler warning for using
varanywhere else. The thing that bothers me the most is to read code that the lazy programmer putvareverywhere. 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 ofvar. In my opinionvarshould 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
In what way is "laziness" bad, concerning typing? Who needs typing excercise? I cringe at the sight of redundancy, and mentioning the type twice in an assignment is redundant. "In my opinion var should only be used to infer anonymous types and nothing else" And how do you rationalize that? Because you think it was made for something else, and should be used only there? It's your personal taste, other than "should.. blah blah", "beginners blah blah" I've heard no sensible explanation of you. Now I don't claim to be a genious programmer, but I'm "in the field" as long as you are plus some small extra years, although not knowing every aspect of every language I need to use. Still I'm quite confident that if there was a really dangerous issue with "using var outside of LINQ", I would have noticed it, I guess I'm experienced enough for that. I just don't see any, from none here who commanted about that, just loads of personal taste statements...
-
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!
-
In what way is "laziness" bad, concerning typing? Who needs typing excercise? I cringe at the sight of redundancy, and mentioning the type twice in an assignment is redundant. "In my opinion var should only be used to infer anonymous types and nothing else" And how do you rationalize that? Because you think it was made for something else, and should be used only there? It's your personal taste, other than "should.. blah blah", "beginners blah blah" I've heard no sensible explanation of you. Now I don't claim to be a genious programmer, but I'm "in the field" as long as you are plus some small extra years, although not knowing every aspect of every language I need to use. Still I'm quite confident that if there was a really dangerous issue with "using var outside of LINQ", I would have noticed it, I guess I'm experienced enough for that. I just don't see any, from none here who commanted about that, just loads of personal taste statements...
Steve#2 wrote:
Who needs typing excercise?
Do you really think that Ctrl+C, Ctrl+V is a painful typing exercise. Better yet, do you really think that, Ctrl+C, Ctrl+V is too much for the sake of readability? Most C# people look at the beginning of the line to verify a type (or a base type/interface). Having a var there will not help at all when one is quickly sweeping the code.
Steve#2 wrote:
And how do you rationalize that? Because you think it was made for something else, and should be used only there?
You don't use dynamic keyword for types known at compile type, do you? Somethings are there for a purpose, so that's what we should use them for. Do you use a hammer as a screwdriver? You could bust something open, but I'd rather not brake it while doing so.
Steve#2 wrote:
"beginners blah blah"
I never said you were a beginner, but beginners do tend to abuse the keyword, specially when they are starting now, when the keyword already exists.
Steve#2 wrote:
I've heard no sensible explanation of you.
I think I already made my point about why you should use tools for the jobs they were designed for, unless you don't have the right tool.
Steve#2 wrote:
just loads of personal taste statements...
Even if they look personal, there are very solid reasons for that. As you should know, OriginalGriff has more experience than both of us combined, it's often wise to trust experienced people.
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 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
usingdirective 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
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
There's definitely something to be said for clarity. Not just from the aspect of someone else having to support or extend your code, but sometimes just coming back to your own code after a period. Something about a hammer and nail comes to mind.
