Using IEnumerable nonsense for everything

[Mark_Wallace]

harold aptroot wrote:

Is this style cancer?

Absolutely! A page full of IF...GOTO statements looks far more organised! You don't even need ELSEs, or any of that indentation that makes the page a mess!

I wanna be a eunuchs developer! Pass me a bread knife!

[Lost User]

Marc Clifton wrote:

readability, simplicity, maintainability,

These might have sold it to me if they were true. They're true for you, but not for me. The functional syntax I see as detrimental.

[Yet Another XCoder]

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…

[irneb]

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.

[HerrGilbert]

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]

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

[Gaston Verelst]

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]

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

[Aunebakk]

Sorting arrays in asp pages is ok I guess. For business logic I would recommend an traditional approach. so, yea, cancer for sure! //ra

[Sentenryu]

Instead having loads of repeated code everywhere for no real benefit? are you trolling?

[Sentenryu]

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.

[Lost User]

I didn't even mention performance, but sure, it aint great.

[Lost User]

Well, you did use some unnecessary stuff there.. temporary list isn't necessary, and those -1's should obviously not be there.

[Lost User]

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.

[Herbie Mountjoy]

Linq => Backward SQL

We're philosophical about power outages here. A.C. come, A.C. go.

[Sentenryu]

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 if but you know what? I much prefer to read

someList.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.

[Lost User]

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

[maze3]

boss: "we need an else statement adding for when 'c' == Who and to run "Heaven(e)" programmer: "right, that will be 2 hours."

foreach(var stuff in someStuff) {
if(stuff == What) {
Hell(stuff + The)
}
else if(stuff == Who) {
Heaven(stuff)
}
}

Boss: We all so need to call Devil() for when stuff it is "What".

[Sentenryu]

It was hard for me too, but once you understand how the context shifts it becomes way easier. LINQ queries have a different flow from the rest of the imperative code and are best left a little separated from stuff like for loops and complex conditionals, they require you to use the same way of thinking you use when writing SQL. It's not that you are telling the machine what to do, you're telling it what you want done, so you read this:

someList.Where(condition).Select(field)

As "Give me field for all objects where condition is true" instead of "For each object, if condition is true, stuff field on another list". Truth is, those kind of LINQ queries are just convenience. The real power of LINQ comes when you start using joins and groups, like this example from LINQPad (still on the simple side):

var query =
from o in Orders
group o by o.ShipCountry into countryGroups
select new
{
Country = countryGroups.Key,
Cities =
from cg in countryGroups
group cg.ShipPostalCode by cg.ShipCity into cityGroups
select new
{
City = cityGroups.Key,
PostCodes = cityGroups.Distinct()
}
};

that produces this output:

// Brazil
// Campinas
// 04876-786
// Resende
// 08737-363
// Rio de Janeiro
// 02389-673
// 02389-890
// 05454-876

As much as I can write that using for loops and conditionas, i don't want to write it that way. Also, join's and group's are the only thing I'll ever use query syntax for, they are somewhat easier to understand that way.

[Richard Deeming]

PIEBALDconsult wrote:

how many times the data gets copied and iterated

Iterated: yes. Copied: only if you use ToList / ToArray / ToDictionary / etc. That's the big benefit of lazy evaluation - nothing gets iterated or copied until you're ready to use it. Of course, if you don't understand what you're doing, that can also the big drawback. :)

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer