Using IEnumerable nonsense for everything
-
Ok OrderByDescending is convenient and having to retroactively put in sorting into normal code is annoying. That doesn't sell it for me. It's still "codegolfing but with longer method names" to me.
harold aptroot wrote:
"codegolfing"
Strange thing there, Harold; last Sunday's crossword puzzle had, as its long-tail-quote, something former US Prez Gerald Ford supposedly said: "I am not getting better playing golf because I hit fewer spectators" Have you ever looked at the XML the WCF serializer generates: object-name prefixes and suffixes can total twenty characters and more. It has become my habit to write long descriptive names in code, even though I am a solo act; part of that is because I want any students who may see the code to encounter such long mnemonic names ... and, partly because I am a speed touch typist, so the perceived "cost" of typing longer names is minimal ... and, of course, ReSharper and the VS editor make name completion a snaparoo. cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
PIEBALDconsult wrote:
Many fans of that style don't realize how many times the data gets copied and iterated when they do nonsense like that.
Many fans do realize, we just don't care :) Would I use the style for loops that should be executed milion times a second, like image processing? No. Would I use it for everything else? Hell yes.
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
Then you're not the problem.
-
Ok OrderByDescending is convenient and having to retroactively put in sorting into normal code is annoying. That doesn't sell it for me. It's still "codegolfing but with longer method names" to me.
harold aptroot wrote:
t's still "codegolfing but with longer method names" to me.
Well, if readability, simplicity, maintainability, and a more functional programming syntax style don't sell you, then I don't know what will. :) And an FP style is often times better because those "long method names" are descriptive of what is happening, rather than having to look at code to figure out what is happened. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
You've probably seen this style if you're done anything with C# after 2007 or so. someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e)); Instead of, you know, a plain old `for` loop with an `if` in it and so on. Or maybe `foreach` if you want to be fancy. So, now we have nearly a decade of experience with this, can we finally settle this question: Is this style cancer? I still think it is, and the retort "you just have to get used to it" isn't going to work any more. I file this firmly under "stupid one-liner 'clever' code with no benefits to compensate". Yes, I've argued in the past that "clever code" isn't necessarily bad, and I'll keep saying that - there's a time and a place for it. But not if you're just trying to be cute. "Oh look at me, I put everything on one line, +1 nerd points for me" And this is even worse. It's not just cute with no benefits to compensate, it's cute and harder to read. Side question, why is this style popular?
harold aptroot wrote:
Is this style cancer?
Absolutely! A page full of
IF...GOTOstatements looks far more organised! You don't even needELSEs, or any of that indentation that makes the page a mess!I wanna be a eunuchs developer! Pass me a bread knife!
-
harold aptroot wrote:
t's still "codegolfing but with longer method names" to me.
Well, if readability, simplicity, maintainability, and a more functional programming syntax style don't sell you, then I don't know what will. :) And an FP style is often times better because those "long method names" are descriptive of what is happening, rather than having to look at code to figure out what is happened. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
You've probably seen this style if you're done anything with C# after 2007 or so. someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e)); Instead of, you know, a plain old `for` loop with an `if` in it and so on. Or maybe `foreach` if you want to be fancy. So, now we have nearly a decade of experience with this, can we finally settle this question: Is this style cancer? I still think it is, and the retort "you just have to get used to it" isn't going to work any more. I file this firmly under "stupid one-liner 'clever' code with no benefits to compensate". Yes, I've argued in the past that "clever code" isn't necessarily bad, and I'll keep saying that - there's a time and a place for it. But not if you're just trying to be cute. "Oh look at me, I put everything on one line, +1 nerd points for me" And this is even worse. It's not just cute with no benefits to compensate, it's cute and harder to read. Side question, why is this style popular?
When I started programming, "some" years ago, people where complaining about the performance of Object Oriented Programming (I won't speak of assembly vs. "high-level" language). A "few" years later, when .NET arrived, the same was said regarding the use of the Framework compared to native code. Nothing changes…
-
You've probably seen this style if you're done anything with C# after 2007 or so. someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e)); Instead of, you know, a plain old `for` loop with an `if` in it and so on. Or maybe `foreach` if you want to be fancy. So, now we have nearly a decade of experience with this, can we finally settle this question: Is this style cancer? I still think it is, and the retort "you just have to get used to it" isn't going to work any more. I file this firmly under "stupid one-liner 'clever' code with no benefits to compensate". Yes, I've argued in the past that "clever code" isn't necessarily bad, and I'll keep saying that - there's a time and a place for it. But not if you're just trying to be cute. "Oh look at me, I put everything on one line, +1 nerd points for me" And this is even worse. It's not just cute with no benefits to compensate, it's cute and harder to read. Side question, why is this style popular?
The "idea" isn't bad per say ... just that it tends to be taken too far. Personally I try to keep such Linq chains down ... at most two dots in such a call (at least that being a quick-n-dirty rule-of-thumb). Especially as a normal for/foreach tends to be more efficient too, your sample is quite litterally performing 3 loops where one for loop would have sufficed. The only time I feel such long chain of Linq extension methods make sense is if using the Linq SQL syntax instead. Though it's still not very efficient, actually less so than the pseudo FP style.
-
You've probably seen this style if you're done anything with C# after 2007 or so. someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e)); Instead of, you know, a plain old `for` loop with an `if` in it and so on. Or maybe `foreach` if you want to be fancy. So, now we have nearly a decade of experience with this, can we finally settle this question: Is this style cancer? I still think it is, and the retort "you just have to get used to it" isn't going to work any more. I file this firmly under "stupid one-liner 'clever' code with no benefits to compensate". Yes, I've argued in the past that "clever code" isn't necessarily bad, and I'll keep saying that - there's a time and a place for it. But not if you're just trying to be cute. "Oh look at me, I put everything on one line, +1 nerd points for me" And this is even worse. It's not just cute with no benefits to compensate, it's cute and harder to read. Side question, why is this style popular?
harold aptroot wrote:
Is this style cancer?
No. Linq has both it's Pro's and Con's. However, there is a clear benefit: Easy to write and easy to read (keep in mind that, if using Visual Studio, you have full intellisense support. And you can use your favourite code template, too.)
someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e));
looks better to me than
List tmpStuffList = new List();
for (int i = 0; i < someStuff.Count - 1; i++)
{
if (someStuff[i] != What)
{
tmpStuffList.Add(someStuff[i]);
}
}for (int n = 0; n < tmpStuffList.Count - 1; n++)
{
Hell(tmpStuffList[n]);
}I'll stick to the LinQ way of Querying. ;)
-
Sander Rossel wrote:
I have no idea why you'd find it unreadable, it reads almost like natural language..
I think the problem is it's the wrong language for me. I don't think in terms of filters and transformations but this style forces me to.
I do think that way, but your style forces me not to. From now on I'll consider for loops a cancer :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Nope, I love that style of programming. It's SO much more readable than a foreach/for/while loop. It becomes immediately clear what the code does. There's some collection than we need to filter, transform and process whereas a loop is just a loop and might do all those things, but you won't know until you read through the loop, probably with a lot more code to keep the new lists and counters. I've found a lot more unreadable loops than LINQ queries. I have no idea why you'd find it unreadable, it reads almost like natural language... :~ Anyway, that style is necessary for LINQ to SQL/Entities (because loops can't build expression trees, convert that to SQL and be lazy evaluated). And if I had to choose between LINQ or plain old SQL I'd choose LINQ wherever possible. Only the .ForEach() is an odd one. It's defined on List and not as a LINQ extension method because ForEach, by definition, has side-effects and LINQ was designed keeping the functional paradigm in mind. I never use it.
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
It becomes immediately clear what the code does.
I think this is the important part. You focus on what the code does, without caring how this is done. As long as it does what it promises (which is the case with LINQ - usually) you're fine. So you're abstracting away how you would (for example) filter the collection.
Check out my blog at http://msdev.pro/
-
Sander Rossel wrote:
It becomes immediately clear what the code does.
I think this is the important part. You focus on what the code does, without caring how this is done. As long as it does what it promises (which is the case with LINQ - usually) you're fine. So you're abstracting away how you would (for example) filter the collection.
Check out my blog at http://msdev.pro/
Yeah, and the how becomes so much more easier to read when you know what it is supposed to be doing in the first place :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
You've probably seen this style if you're done anything with C# after 2007 or so. someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e)); Instead of, you know, a plain old `for` loop with an `if` in it and so on. Or maybe `foreach` if you want to be fancy. So, now we have nearly a decade of experience with this, can we finally settle this question: Is this style cancer? I still think it is, and the retort "you just have to get used to it" isn't going to work any more. I file this firmly under "stupid one-liner 'clever' code with no benefits to compensate". Yes, I've argued in the past that "clever code" isn't necessarily bad, and I'll keep saying that - there's a time and a place for it. But not if you're just trying to be cute. "Oh look at me, I put everything on one line, +1 nerd points for me" And this is even worse. It's not just cute with no benefits to compensate, it's cute and harder to read. Side question, why is this style popular?
-
OriginalGriff wrote:
Would you like to write and debug "Except" each time you need it?
Actually yes, so I wouldn't end up in that situation of horribly nested function calls in your second code block.
-
The "idea" isn't bad per say ... just that it tends to be taken too far. Personally I try to keep such Linq chains down ... at most two dots in such a call (at least that being a quick-n-dirty rule-of-thumb). Especially as a normal for/foreach tends to be more efficient too, your sample is quite litterally performing 3 loops where one for loop would have sufficed. The only time I feel such long chain of Linq extension methods make sense is if using the Linq SQL syntax instead. Though it's still not very efficient, actually less so than the pseudo FP style.
irneb wrote:
your sample is quite litterally performing 3 loops where one for loop would have sufficed.
you should really take a look on what the compiler does when it enconters the yield keyword, you might be surprised to find out it's not as inefficient as you think.
-
When I started programming, "some" years ago, people where complaining about the performance of Object Oriented Programming (I won't speak of assembly vs. "high-level" language). A "few" years later, when .NET arrived, the same was said regarding the use of the Framework compared to native code. Nothing changes…
-
harold aptroot wrote:
Is this style cancer?
No. Linq has both it's Pro's and Con's. However, there is a clear benefit: Easy to write and easy to read (keep in mind that, if using Visual Studio, you have full intellisense support. And you can use your favourite code template, too.)
someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e));
looks better to me than
List tmpStuffList = new List();
for (int i = 0; i < someStuff.Count - 1; i++)
{
if (someStuff[i] != What)
{
tmpStuffList.Add(someStuff[i]);
}
}for (int n = 0; n < tmpStuffList.Count - 1; n++)
{
Hell(tmpStuffList[n]);
}I'll stick to the LinQ way of Querying. ;)
-
It's literally a single "if" that's added into a loop. That's not enough to refactor out of it, anything it can be replaced by is at least as complicated. Writing an "except" method is certainly more complicated, and calling it isn't any simpler than what it replaces.
-
I use it - though not the .ForEach on the end - because there are times when it provides a reliable, succinct, and clear way to process list (or other collection) based data.
var vidsWithOutPics = vidList.Except(vidsWithPics).Where(v => !v.IsAlternateTitle);
Or
var inDuration = DiskFile.GetAll().Where(df => !df.HasDuration).Select(df => df.Video).Distinct();
Or
var noSizeList = videoFiles.Where(file => file.Bytes < 0 && files.Contains(file.Location));
All I'm doing is "hiding" the loop so I don't have to write it! Yes, I could write each of those as loops - they aren't at all complex - but they would be longer; they would need debugging each time I wrote them. The other alternative would be to use Linq syntax, and that's pretty horrible!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Linq => Backward SQL
We're philosophical about power outages here. A.C. come, A.C. go.
-
It's literally a single "if" that's added into a loop. That's not enough to refactor out of it, anything it can be replaced by is at least as complicated. Writing an "except" method is certainly more complicated, and calling it isn't any simpler than what it replaces.
this thread only shows that you're hellbent on your "One true way" of coding, so there's not much to discuss here. but do keep in mind that calling a style "cancer" just because you don't want to learn how to read and use it is exactly what causes so many flamewars on the IT world (tabs vs spaces anyone?). Sure, you tell me it's just an
ifbut you know what? I much prefer to readsomeList.Where(condition).Select(fields).Distinct().OrderBy(field)
than the alternative
HashSet distinctSet = new HashSet();
foreach(var item in someList){
if(condition){
distinctSet.Add(item);
}
}specially if you want to roll your own sorting method at the end. As a last note, i sometimes work with code where the order of operations (where, distinct, etc) sometimes yields different results and is important (due to crazy business rules, what can you do), so it's way easier to get the intent from the link way, but I recognize that you mileage may vary on that last one.
-
this thread only shows that you're hellbent on your "One true way" of coding, so there's not much to discuss here. but do keep in mind that calling a style "cancer" just because you don't want to learn how to read and use it is exactly what causes so many flamewars on the IT world (tabs vs spaces anyone?). Sure, you tell me it's just an
ifbut you know what? I much prefer to readsomeList.Where(condition).Select(fields).Distinct().OrderBy(field)
than the alternative
HashSet distinctSet = new HashSet();
foreach(var item in someList){
if(condition){
distinctSet.Add(item);
}
}specially if you want to roll your own sorting method at the end. As a last note, i sometimes work with code where the order of operations (where, distinct, etc) sometimes yields different results and is important (due to crazy business rules, what can you do), so it's way easier to get the intent from the link way, but I recognize that you mileage may vary on that last one.
I promise you I'm not just flaming, I just really find those chained LINQy things hard to read. It's not like I haven't tried, I've been reading them for nearly a decade, I'm not getting used to them. It takes an extra step in my mind somehow, normal code I read and build up a picture of it in my mind, LINQy stuff I read, tear down, then build a picture. Clearly that is not the case for everyone here
