'Stop Using LINQ in .NET!'

Hello, everybody, I'm Nick, and in this video I want to talk about one of the most insane things I've seen on Reddit regarding employers banning the use of LINQ in the entire company.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[sealsharp]

1) ban LINQ
2) write your own methods
3) write the same methods again and again
4) collect common methods
5) make a library of common methods
6) have LINQ without MS doing the unit tests for you

[ericblankenburg]

I've been in software architecture and development for 30 years. I have found that there are a lot of people in positions of leadership in the industry that shouldn't be there.

[valeriesimpleton]

I don't let anyone on my team use classes they're too risky

[sasukesarutobi]

"LINQ is hard to read/debug" <- literal skill issue. With very little practice and a fairly shallow learning curve, fluent use of LINQ extension methods are very straightforward to read and reason about, and help make code functional yet readable. Sure, sometimes you might want some intermediate variable assignments if you're wanting to follow object states, but techniques to debug LINQ aren't particularly arcane.

[hodgenick]

I would change employer. What an idiotic mandate.

[Linkario]

Wtf? I really didn't expect this to get so much traction.

But I'm a Nick Chapsas Video. Cool! :D

[Krimog]

Here's my take: the only scenario where you should not use LINQ is when you have extreme performance requirements. But you have to be an experienced developer to write faster code than LINQ. And if you are, you don't need someone to tell you that you should not use LINQ. So the "Do not use LINQ" rule is, at best, useless, and most of the time, bad.

[yupii]

At my first internship we werent allowed to use Include, or any type of SQL joins.
The reason?
The manager said it could mess up the database.
So instead if we wanted to get the related data we had to send multiple database calls in order to get the data we needed.
Good times

[Tsunami]

Not often, mind you, but there definitely have been some times where query syntax led to improved readability of existing code.
e.g. chaining multiple "from"s automatically does a SelectMany(). And there's no direct function-syntax equivalent to the "let" keyword for introducing an intermediate variable.

[supreme_dev]

The only situation where we've been avoiding linq is in game development, more precisely in Unity where we are on .NET Framework 4.8 where linq is pretty allocation heavy and slow so we implement most of the stuff carefully, that's the only place I could understand avoiding linq (or any similar scenario), otherwise this is completely sad

[PetrVejchoda]

var sum = 0;
for (var i = 0, i < 1000; i++)
{
var value = i*2;
if (value > 20)
{
sum += value;
}
}

This will be faster (slightly) and doesn't read as bad. It is more straightforward in the means of that you kind of know what is going on if you step through this with a debugger. However the extension syntax of linq is still far superior in readability for me.

We were not allowed to use linq back in the days when I was working in Madfinger games, in Update methods, in Unity since it was always allocating new enumerator and there was not way to reuse them or make it allocationless. We were discouraged of using it elsewhere either, for the reasons of "harder to debug". Since it was my first job in C#, for a long time I was afraid of linq. But when I learned it, I am always trying to explain how great that is to people programming in other languages (or c# devs who do not use it).

[DevMeloy]

I know I'm in the minority here, but I like LINQ query syntax. It reads more like SQL and in my experience easier to write certain complex queries in.

[alejandrocoto]

@Nick Your example doesn't help case for LINQ, mainly because non-LINQ code (if you take a step further and remove the List) runs 8 times faster than the LINQ code without any memory allocation (the LINQ code still have some bytes allocated) and the readability is not that worse. Maybe if the example is not trivial, with a GroupBy or OrderBy maybe, where the non-LINQ code would explode in complexity and have significant worse readability can better support the case for LINQ. Another example that would help, will be an optimized LINQ method, that may use SIMD behind the scenes, which is not easy to write or read without LINQ.

For the record, I think that decision is nuts and LINQ have it's place, maybe not that much in hot-paths, but you don't want to throw it away like that.

[damienfenton]

Reminds me of the time my boss was in a panic about a new calculation that wasn't covered by an Excel spreadsheet's existing formulas. I said a simple change to one of the formulas would resolve the issue but she was too scared to change it because "the formulas are too important to mess with". The result was an additional two hours of manual calculations per month which also increased the risk of human error.

[Matt]

I actually do use the LINQ query syntax, albeit very rarely. Basically if I need to do something like joining two collections together on some common key, I find the extension method syntax harder to read once you start having to pass multiple lambdas. Aside from those types of uses, neither syntax is harder to read than the other so I default to extension method syntax.

[mdrtoffee]

Banning LINQ across the board is a ridiculous decision. But if it's in the context of using it to generate queries from a DB via EF then I'm all for that. Avoid EF like the plague, write your own SQL queries and then use a lightweight ORM like Dapper. Any good developer should be an expert in writing SQL.

[FlorianDelorean]

At a job in my junior years (13+ years ago), I was forbidden to use "goto"... But not just the keyword, if a comment or variable had the word "goto" in it, our "quality gate" would find it. The quality gate you ask? Full text search in all solution files... Also, it would NOT prevent the check in into the branch, but send an email to the manager about this "incident". The manager left before I did.

[igorsolomatov]

I find the only issue is that it silently falls into memory execution, because somebody used something like a custom function. But the “where” was applied down the line. So it has to load almost everything.

[tallnavyguy]

For the first LINQ example, I can think of a much less expensive way to "write it out by hand:"

var oldSum = Enumerable.Range(0, 1000)
.Select(x => x * 2)
.Where(x => x > 20)
.Sum();

Console.WriteLine(oldSum);

var sum = 0;

for(var i = 0; i < 1000; i++)
{
if (i < 11) continue;

sum += i*2;
}

Console.WriteLine(sum);

If you run the code, both Console.WriteLine() statements should give the same result. But, notice where Nick did two loops -- one loop to make a list of the doubles of the numbers from 0 - 999, and then a second loop to compose the sum, I can do it with just one for loop.

I know that 10 * 2 = 20, and I only want to take the sum of those values in my doubled sequence that are strictly greater than 20. Okay, that is easy. If i < 11, then simply skip to the next loop iteration. Otherwise, add 2 times i to the sum.

You can benefit to do a little math first.

[keyser]

This dogmatic overbearing "you must!" or "you must not!" attitude has been pervasive in software dev for a while now. It's funny some people are just now raising the flag. I don't think most devs even realize they're guilty of it themselves. One size doesn't fit all, so let's all get better about not being _that_ guy.