The new GOTO Statement?
-
Perhaps embedded method is a loose term. This is what I'm referring to. In my opinion it reflects the same goto example you posted.
public string ReturnSomething()
{
// ... some logic
// ...
var compare = new Func<string, string, string, string, bool>((compare1, compare2, compare3, compare4) =>
{
return (compare1.Equals(compare2, StringComparison.InvariantCultureIgnoreCase) &&
compare3.Equals(compare4, StringComparison.InvariantCultureIgnoreCase));
});// some more logic flow // .... if (compare("a", "b", "c", "d")) { // some logic } return "Something"; }
I fail to see anything like goto in your example. Flow branching into a function when it is called is all I see, and that happens all over, every second in C#. The key difference here is that without using goto in your function body, you are still guaranteed a return to just after the line that calls the function.
-
Yes, you can abuse lambda's and make a mess. You can abuse goto and make a mess. You can abuse boolean variables to simulate some forms of goto and make just as big a mess. You can abuse operator overloading and make a mess, and when James Gosling says you can't have operator overloading in Java, you can make just as big a mess with method overloading and virtual methods if you set your mind to it. You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is), which is like a goto where you don't even know for sure where it will go. You can abuse pretty much every aspect of a general purpose programming language.
Then some guru comes along and declares any one of those language features dangerous and unsafe. The followers of the guru create a cult around that and go a little further by creating the sacred commandment 'Thou shalt not use (whatever)'. The following crusade will take years, but in the end we have nagging code checking tools that assume to know better than that overpaid code monkey in front of the machine.
harold aptroot wrote:
You can abuse pretty much every aspect of a general purpose programming language.
That's exactly why the gurus will never run out of work. In the wrong direction, if you ask me. Coders who have been trained to follow rules blindly are very helpless when something goes wrong. That costs time and money instead of making anything safer or more productive. If you, my special Java friends, happen to read this: Your current problems will end the day you finally start thinking, throw out the holy commandment not to manage memory and analyze your code. Or you can spend some more years trying to beat the garbage collection into submission. :)
At least artificial intelligence already is superior to natural stupidity
-
Bad Software languages breed bad software engineers....
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
var
is great for foreach loops when you have long types like KeyValuePairs with a generic type for the value. I don't use it often outside that.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
-
harold aptroot wrote:
You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is)
Are you saying that you can have a case statement without an enclosing switch? :wtf: What does THAT look like, and what would one use it for?
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.
-
Yes, I agree. Every element of a language has it's use - even
goto
andvar
in 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.var
should be banned outside Linq!Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
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>.
-
Perhaps embedded method is a loose term. This is what I'm referring to. In my opinion it reflects the same goto example you posted.
public string ReturnSomething()
{
// ... some logic
// ...
var compare = new Func<string, string, string, string, bool>((compare1, compare2, compare3, compare4) =>
{
return (compare1.Equals(compare2, StringComparison.InvariantCultureIgnoreCase) &&
compare3.Equals(compare4, StringComparison.InvariantCultureIgnoreCase));
});// some more logic flow // .... if (compare("a", "b", "c", "d")) { // some logic } return "Something"; }
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.
-
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.
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.
-
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.
-
Yes, I agree. Every element of a language has it's use - even
goto
andvar
in 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.var
should 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:
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 putvar
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 ofvar
. In my opinionvar
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
-
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
using
directive 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
var
was 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
using
directive 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
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
-
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:
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 putvar
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 ofvar
. In my opinionvar
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
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 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: )
-
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
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