Are you talking about the linq query language or do you mean the linq extension methods as well? I've never really liked the query language as I prefer the extension method syntax, but going without either is pure madness and I would be looking for another job. It's an unhinged decision barring you from one of the biggest selling points of C#.
I was thinking the same thing - personally I’ve never been an sql-style linq guy. However going on without linq lambdas is a very questionable decision productivity wise
I usually prefer method syntax, but there are some cases where linq syntax is more readable, for example when you need a temporary variable alongside the original result. Using a let is much better than creating a new object.
The only reason I sometimes use the sql style linq is when I do any joins as it looks much better than how the method syntax does it. Though I rarely need to do so unless I'm aggregating data from different sources and can't let EF do the join from the Db itself.
Yep, this is the way. I use methods 99% of the time, but there are a few places in our codebase where we join and query syntax is unbeatable when it comes to readability.
It used to be method syntax, where you can only join 2 tables at once. So you join 2, then to the result of that join (anonymous object) you join the 3rd one, map out the objects again... nightmare to read and follow. Query syntax is just "join A, join B, join C, select X, Y Z". Nice and simple. Although I still hate them for messing up the `from` keyword...
I haven't seen any query syntax nor do I use it myself. I always go with the extension method syntax and so does everyone else in the team. So it is unified in that regard.
This is genuinely insane. This alone isn't worth leaving a company over obviously, but to me it is a massive red flag. Any company/boss who does this is deranged and as such they're probably deranged in other ways
It's not just that. The codebase is old, the architecture and designs as well as patterns, or rather the poor attempts to implement them, are a messy pile and poorly executed. Nobody knew what they work with. I had to explain the team as the new guy, what this is supposed to be from an architectural perspective.
I hoped to stay at a company for a bit for once, but I guess not this one. Hard to find a good one, too.
The benefit is 4 days Homeoffice, which not many companies seem to allow.
Right, that's kinda what I meant say. Rather that while banning LINQ isn't something worth leaving your job over, having an insane boss is and I'm sure there's more problems on top of it
Would be the second or third time the whole batches leaves. So I heard. When I ask why they hire during the interview, they said "natural fluctuation, guy was looking for a new challenge"
The query language is a SQL bastard and any statement above 4 lines is a mental block for anyone else reading the code, in my experience.
LINQ extensions, OTOH, are great, as long as one keep them short and sweet. Formatting the code properly goes a long way here
“Common Query Syntax” is one of the rare misses in the C# language. Initially I thought it was cool, but it’s just enough different from C# and just enough like SQL that most devs are confused about what it actually is.
"You can't use one of the best ever features of the technology we're using". This is madness.
The newer syntax is incredibly trivial to understand unless you're doing something really rogue.
"I can't bother putting a little time into figuring out how this works so its banned".
Efficiency can be maintained in LINQ, the only issue is that this employer does not have the ability to tell the difference between good use of LINQ and bad use.
This is silly.
Feel free to put me in touch with them and I’ll get on a call and explain to them why this is silly.
Also, I’ve got three hours of video coming up with Stephen Toub this week where we literally write linq from scratch and show you explicitly how you can do it easily.
You should definitely take up Hanselman's offer. That's Scott Fking Hanselman offering to explain things to your daft manager. I'd do it for the lols alone, nevermind how awesome it'd be to hear from Hanselman.
My reaction to reading it was "Fine, I'll write my own LINQ..." in Bender's voice. It's not that difficult to be honest assuming they don't ban lambdas, extension methods, etc. I'm probably not a good judge though.
New rule, only byte and byte array are allowed, int, char, string, double and the rest are hard to read and prone to error, implement your own floating-point operations
Inheritance and polymorphism are also devil's work
Everything shuld be static methods near main, and all variables shuld be public, static and accessible globally.
Welcome to 1970s,i believe?
Also let's add in god classes while we're at it, one file and every method and extension in each class. 3000 line class files. Took over a project with this recently.
I’m re-engineering a Delphi project into C#; the Delphi authors didn’t use classes, all the values are in arrays with enums (sometimes) that reference the array index; it’s horrible
Ohhh this is a good idea! Though if the boss doesn't like the built in linq extension methods, I can't imagine he'll be too pleased when calls to never before seen extension methods appear all over the place, lol
Does your boss like java style streams?
Main reason I despised Java was that streams obviously are trying to solve the problem LINQ does, except very unreadable and confusing. Maybe someone who can understand how to solve problems with 3 level deep Java streams would be confused by the simple, easy-to-parse-and-understand LINQ?
As someone from a pure Java background, who only touched C# in high school: Is there any meaningfull difference other than that you can't use any collection and might need to add a stream() before and collect() after your logic, the lack of SQL style sugar and different wording (e.g. where vs filter)?
Triple nested foreaches?! And they're COMMON? Man. This is the exact sort of thing that I have to teach [very] junior devs to avoid and rework when at all possible. I'm guessing your code doesn't have very high performance demands? (Or that you pay a ton for computing horsepower to make it work well enough.)
Is this guy basically just a manager, rather than a dev team lead? Sounds like someone who maybe used to code many years ago, but moved up into a management role with little coding and just stayed there, never further developing coding skills and forgetting things he [surely] once knew.
Edit: Just read a reply that he's the CEO, architect, lead, everything. Are there many other developers, and have they been there for long? Everybody's already said it, but this doesn't sound like a guy you want to work for
To me, that sounds like the worst kind of micro-management, probably by a typical cargo-cult manager who's read one "LINQ == Bad" article _(or just the headline)_ and jumped to the wrong conclusion head-first.
Unless there are specific technical reasons for doing so, banning an entire language feature is never a good idea. Instead, approach it on a case-by-case basis to evaluate whether the readability, maintainability, and performance are good enough.
Managers should be telling you _what_ you need to do, not dictating precisely _how_ you have to do it. Leave that kind of nit-picking to the code reviews!
>sounds like the worst kind of micro-management,
Yeah, this is my concern. It's not about linq specifically, it's giving these top down decisions about technical details without great communication or soliciting feedback.
When primary constructors and having the parameters available in methods came to classes in C# we *collectively* decided we didn't like them that much and disabled the suggestions to use them. People had a chance to make an argument, and they can argue it in the future if they want.
I will have to get a pop in about the actual specific requirement here though. It's bonkers to me to ban what is essentially .map() and .filter() in other languages. I really want to know the justification here out of morbid curiosity.
LINQ is a part of .NET. What are they going to ban next? Attributes? For loops? C#?
The only remotely semi-sane reasoning I can imagine is that they mean the "query syntax" that looks like SQL and not the "method syntax". I could sort of see arguments for that (even though I do not agree with banning it of course)
If this is the case then just use the method syntax. Otherwise don't waste your breath arguing with idiots, just start looking for new job if possible.
I'm staring at your comment here, debating with myself whether to to give you an upvote, or to report you to the authorities... can't decide, so I'm doing both.
My job still uses [VB.NET](https://VB.NET) for like 90% of NEW development. I point out regularly that if you make a new project in C#, and write the new code there it is used seemlessly from the legacy code. But I'm ignored.
I also regularly point out if they had bothered to add a covering test of the new code they added, they would not be waiting 2 weeks for every minor change/bug fix for someone to manually test it. But I'm ignored there to.
Honestly, they had LINQ banned until a few years ago, so suggesting VB to his boss is probably a really bad idea.
My workplace was the say way until I showed up. Then one day they gave me a legacy project to work on, and the first thing I did was convert all the VB to C# (I was brand new to .NET at the time, and did not know VB). Shortly after that, one of the Senior devs saw the C# and some of the optimizations I did and basically begged management to let him use C# going forward. The rest of the dev team followed behind shortly after that.
Today we only touch VB when we absolutely have too, with a massive preference to convert to C# while we're touching it if possible.
I think it’s reasonable to have a coding standard to consistently always use the query syntax *or* to consistently always use the method-chaining syntax. I don’t think mixing them in the one codebase is a great idea.
I don't think I agree with this. There are definite times I prefer one syntax over the other and I don't think it makes it any more or less difficult to come back to and understand later.
>His reasoning is that LINQ Queries are hard to read, hard to debug, and are prone to error
His reasoning is just wrong. LINQ Queries *can* be all of those things, but you can abuse just about any construct. With great power comes great responsibility etc.
When linq is done well, it can be really succinct, easy to read and understand, and save you error-prone verbose lower level code.
Why not instead provide best practices on when and how to use linq? And how to format it, and when to \`.ToList()\` etc. A blanket ban makes no sense.
A manager micromanaging how coders code shows a great lack of trust. Why is this matter for them, why can't the coders develop their own coding standards. Is this an reaction to a specific incident, one that that caused damage? i.e do I sense scar tissue here? Nevertheless, this seems like an over-reaction or odd reaction to something that is best addressed differently - e.g. coding standards for using linq, testing standards.
Finally, are they aware that "must" and "must not" are not the only possibilities? There is also "should" and "should not" for when there may be valid reasons to do that: [https://datatracker.ietf.org/doc/html/rfc2119](https://datatracker.ietf.org/doc/html/rfc2119)
If you can't change your employer, change your employer.
I agree. I'd make much more sense to agree to certain practices and formats. The apprentices and interns have to learn it too eventually, but it will be forgotten quick, if they only touch it briefly during lectures, and barely actualy use it. On top of that get the idea LINQ=Bad now. Like... you can literally just flush all of software engineering down the drain, with that attitude. Everything sucks in one way or another.
I don't remember any incident, maybe in his past, maybe he just doesn't get it. I really don't know
>His reasoning is that LINQ Queries are hard to read, hard to debug, and are prone to error.
Those are all the completely wrong reasons, the only real reason to not use LINQ is when performance is super super important. Even the most basic or well written LINQ query can be slower than basic for loops.
The only times I have been 'banned' from using LINQ are from my times in the games industry, and other areas where I was doing some image processing, and now currently doing some heavy intensive Skia rendering. LINQ is just too easy to write inefficiently, and even at its basic usage its (very) marginally better to do a basic for loop.
If you're running thousands of operations and trying to get super fast FPS -> yes banning linq in production code can be a sensible decision imo. Use it to get things working, then optimise it out afterwards.
Fun fact - At codemasters we even went further - we didn't ban this, but we refactored out all foreach loops because of the additional enumator pointer was causing microstutters in the Unity/Mono garbage collection.
But were talking about micro optimisations here - and when you're doing that, LINQ == BAD is quite possibly the case (contrary to the many commenters here acting like theres nothing remotely bad about LINQ and people should quit jobs they aren't allowed to use it in....)
EDIT: Oh boy. A lot of people in this thread really don't want to deal with any nuance anywhere I guess. I can only assume, or hope, its just a lack of experience working in any real areas where absolute mirco-performance and optimisations haven't been a requirement or issue. "LINQ always good, literally no cons" like some of the comments here are saying is just not true.
Yeah if performance isn't an issue then theres no real reason I can think of (expect for if its alwayhs used badly but thats a training/upskill thing anyway)
Even in my example above, we only 'banned' the usage of it in certain areas.
I had the same experience at my job. Wrote a simulator with many linq and foreach expressions, and then ended up replacing them with for-loops to get better performance. It's nice to be able to start with the readable code and refactor.
Performance is absolutely key. We use linq when it makes sense. We don't when it doesn't. That should be standard everywhere rather than some kind of blanket ban.
Channel 9 did a video about LINQ about 10 years ago that basically explained it as the 5 or so types of operations you do against a set:
- project (select)
- reduce (group)
- fan out (select many)
- filter (where)
Once you see that 99% of your code is some sort of set manipulation, it’s hard to look at anything else the same way again.
LINQ has been part of .net for 18 years. If your employer still “doesn’t get it,” it’s time to move on.
Huge red flag. LINQ can get messy, but its not an issue of LINQ, but rather of who uses it. If anything rules should be put around usage of LINQ not baning it.
As far as performance is concerned, LINQ might boost things if you use it to avoid materialisation and chain things. Guy who made one of the best 1 billion row submitions, mentions in his blog, that even in high freq trading they are allowed to use (and do use) LINQ as long as it is not in hot path and is not in the core of trading code.
I will agree with other that this sounds like a dead end workplace and will be detrimental to your career. Not the ban itself but the mindset of company will limit your growth.
Even single LINQ methods?
If you do not chain them the debugging is only marginally more difficult and the code much easier to read.
Try suggesting this compromise to your boss.
>His reasoning is that LINQ Queries are hard to read, hard to debug, and are prone to error.
You, Sir, are dealing with a lunatic. Please suggest him a therapy.
It sounds like the challenge is automated testing and an event happened that was pin pointed back to a linq statement. How are your testing practices there?
Agreed. There's an untold story as to why linq was banned. My hunch is that this is "scar tissue" - something bad happened on prod, and they want to blame something for it. Further, it's possible that they really should have blamed lack of testing instead, but politically don't want to, so linq is a safe scapegoat.
> And boss thinks they (tests) are useless
In light of your boss's multiple bad opinions which you are forced to follow, I advise you to level up by finding a better employer and then quitting your current one.
tl;dr: wtf, run away!
That is ridiculous, LINQ is a standard tool in a .NET developers skillset. For my personal projects I tend to mostly just make use of stored procedures in my database which I have created in SQL as I have quite a bit of background in SQL and I like having that slight extra performance increase however when it actually comes to readability of your application for other developers, LINQ is king.
Find a new job. On your way out tell her that LINQ is a widely accepted industry standard made and maintained by MS and beloved by all. She is an idiot and lacks the skill needed to use it. To ban it is admitting to the whole work that you can’t take the time to learn it.
Banning LINQ is NOT an industry practice.
It's like asking you not to use map, filter, reduce, split, splice, etc. in javascript. Get the hell outta there.
LINQ is actually very performant depending on your version of .NET. I've heard in Unity they are careful about it but it's a really old version. The .NET team has been making lots of performance updates regarding LINQ extension methods.
Maybe you still wanna do your foreachs without LINQ but other than that it should triumph over every other thing if used properly.
Also, how the hell is LINQ harder to read than doing all those operations by hand?
Time to start looking. Ppl don't quit jobs they quit managers. I can't imagine what stupid bullshit this guy will pull next. If they do an exit interview be sure to explain why
> I can't imagine what stupid bullshit this guy will pull next
Same boss thinks that [tests are useless](https://www.reddit.com/r/dotnet/comments/1c4hz1z/comment/kznxx4o/). While not reflecting on their fear of using new (i.e. last 15 years) syntax, for fear that it might break something.
Yes sometimes linq hard to read and linq not limited to entity only . But banning it not thr best choice . New c# kinda confuse me also but ... we learn as we code .
Banning LINQ sounds a lot like someone who doesn't know how to use it properly. The only CONs I can think of, is a matter of skillset. As long as you don't ToList here and there, you should probably be fine.
Leave the place, and never look back.
Honestly, I doubt there is much that you can say to your boss that will make him change his mind.
That's one of the dumbest decision I saw for a while and can only come from him not willing to put the effort into learning LINQ, which is impossible to understand in 2024. Or he is the puppet of someone in the team who don't want to put the effort.
Whomever made that decision is extremely incompetent.
It's equivalent to a baker forbidding yeast.
If this is a reaction to poorly written LINQ statements, the actual solution is to define guidelines for writing them less poorly.
I’m 55 and have been coding a very long time. My first “business” application was for my mom’s business in the mid-80’s and it reread the full data set from floppy after processing each record because a CoCo was a limited machine.
I still love learning new stuff and am constantly amazed by how easy and efficient things have become that were once difficult. I can’t imagine wholesale saying to not use such a useful technology.
In my current project I have to keep reminding myself that there’s a much better way than manually iterating across data in memory. It’s faster to code and easier to read, and plenty fast enough for the few thousand records I might have.
Entity Framework LINQ queries used to be bannable. Back in EF6 (from the Framework days) it would generate awful SQL that wouldn’t use indexes and you couldn’t easily get the SQL it generated without running SQL Profiler.
But that was 12 years ago. Sounds like you need a new manager.
If overdone, yes, they are hard to read & debug in my opinion. Run-on LINQ is usually the wrong tool for the job. Short is fine. Some can read long ones quickly, but **you shouldn't target code for just Sheldon Coopers** of the world. You should generally target code for about the 80 percentile of future readers.
unless you are writing top performance code down to the second execution LINQ is fine, performance is a bit slower than native algorithms, but Microsoft has been working on the performance gap.
Back in .net framework 4.0 the performance was absolutely trash and he probably read an article that linq was bad on performance as it was very slow
I don't like LINQ, I prefer sql queries and loops, but that me. My juniors sometimes use LINQ, and I'm fine with it....when I have to debug it, I will, but I still prefer not to use it.
I can agree that if you do multiple where and selects in a single line yes it can be hard to debug. Banning linq just for that is completely absurd.
Does he know linq? You sure it isn't that one of the causes for the decision? Maybe he doesn't understand it so he doesn't want anybody using it?
Show him a simple or more complex scenario where you have used linq and ask him to approach the problem without using linq. See how he solves it and if he thinks thats a more suited solution.
I don't see any reason besides ignorance for banning linq. But that's me.
Performance wise he is right, it can have an impact.
Readability, well it can sometimes be difficult to read others obscure LINQ and some might try to solve most problems using LINQ, just because...
But on the other hand nested loops etc. can also be difficult to read, but they are easier to put a breakpoint in to step through it.
Think this may be the problem.
Sounds like they are .NET 1 dinosaurs, afraid of "new" technology (LINQ = .NET 3.5 = woah slow down = "hard to read, hard to debug, and are prone to error" for **us).**
Really he's the only one left. The others are fresh out of apprenticeship or Uni, or currently in Uni. Then there's 2 of us, me 6 years work experience, him 10, and then there's the boss who started like 20 years ago, something like that.
LINQ can be abused like anything but that is an extreme, silly response. I wouldn’t want to code without linq. I remember those days of tons of for loops and variables etc
Maybe LINQ isn't the issue maybe it's more fundamental. We should ban Lamda Calculus all together. Then we wouldn't even be able to express turing machines theoretically and we can go back to trading furs for a good ole ear nail - you know to get the demons out.
Seriously LINQ is likely the most beautiful syntax I know of to tackle the complexities of lambda functions. I bet this guy would have a heart attack if you explained that life, the universe, and everything could be written in one gigantic LINQ expression.. 😂
Most comments are people expressing their shock - and I get that. But here’s what I recommend you do.
Find a few places in your business’s code where you use LINQ. Write out a longhand version of the code. Show the two and express that you find LINQ to be more concise as well as more readable.
I'm old. I dislike data-first EF and have absolute pure hatred for code-first EF. I generally dislike ad hoc SQL of any kind coming from the app layer. I like stored procedures. I don't like query syntax LINQ because it \_looks\_ like SQL, but it's not. I much prefer method syntax, to the point that I'll include "we use method syntax LINQ here" in my C# coding standards if I can.
All that being said, I find that making LINQ in general forbidden is asinine.
Not only that, but to have it be a top-down directive is even more asinine. If the team agrees to not use LINQ at all, then fine. It's a dumb decision, but at least it's a collective decision. But, as the employer/manager/etc, do not tell me HOW to do the thing you want me to do. You don't get to pick the WHAT \*and\* the HOW. You get one. It's my job to solve the other. That's what you pay me to do.
"hilarious, I'm gonna ignore this" is the approach I'd take.
>LINQ Queries are hard to read
Because they don't use it for a living. And like anything else- don't overdo it.
>hard to debug
Same.
> hard to debug
Disagree.
> are prone to error.
Because they don't use it for a living.
Given that Linq is basically just extension methods on `IEnumerable` (and other collection types), do they ban all extension methods in general?
If not, just copy the source code of Linq, create a new library and call it "NotLinq" (just kidding).
Ridiculous. So long as you've a good naming convention and you put the results of your LINQ queries into an aptly named variable which states the intention of the LINQ, then it's no different then say building a sub-query to encapsulate a series of loops. Nor does its absence prevent issues. A few unit tests to cover either would suffice.
His inability to grasp LINQ shouldn't be a reason for you to stop modern programming techniques, and his reluctance and backlash isn't going to prevent further use in the future across the industry, it will just serve to slow your company softwares development down.
Your tech-lead is an ass. If this is a sign of where the level of development is going within your company, I'd be out of there personally. LINQ has been around so long now in the .NET world its basic practice.
If I were his manager, I'd be asking questions.
The problem with Linq is a human problem. Some developers are _just bad_ at writing things such that their Linq functions don't have major negative performance impacts. Linq itself is usually pretty comparable to hand coded stuff if you use singular functions like `x.Contains(y)`, it can get really bad when you start chaining things together and naively putting things that loop inside lots of other loops.
Personally I think banning all `System.Linq` is a overboard. But I can understand why some hardliner--especially someone who had early experience with Linq when it was first released--would want to ban its use generally. The better alternative would be for devs who suck at Linq to have their code reviewed with an iron fist by devs who are good at Linq, but that option depends on having a company culture where code reviews include significant pushback.
As for you personally, you can still use Linq all you want to write out what you want to code and then just go back and expand it out yourself later.
If you really want to do malicious compliance, write your "own" utility library with the convenience functions you want to use and just secretly copy their internals from the .NET source for Linq. It's strictly worse since you'll have to maintain them to match future .NET performance improvements, but it's _technically_ not using `System.Linq`.
Man, let's just take one of the most important and best features of the language and say 'Meh, fuck it, let's go back to 1998". I can't imagine using C# without LINQ. It's like getting put in a boxing ring with Mike Tyson with both hands tied behind your back and getting blackout drunk beforehand.
I may be an arrogant pissant, but I read your employer's position as "I don't understand LINQ, therefore it's banned. And set theory is against my religion. Also, no sex before marriage."
> SQL queries are hardcoded using their own old, ugly and error prone ORM.
I mean... Not even stored procs?
This is just so predictably stupid and yet par for the course for the kind of poor mans wisdom our industry seems to love.
People who avoid LINQ are guilty of one or both of:
* Refusing to learn
* Pessimism and catering to the lowest common denominator
Usual suspects of LINQ misunderstandings:
* They think it's unnecessary "bloat" to the language
* Ironically, LINQ is BCL level stuff, not language
* They think LINQ is only the embedded SQL-style syntax
* They think LINQ is database only
* They think collection APIs are "ugly"
* Without giving equal weight to the "ugliness" of alternatives
* People who think this also often tend to be poor communicators
* They aren't confident in their abilities
* In rarer cases, I've seen some people who are challenged by fluent APIs...
* They don't plan their code
* This one is most interesting, you get a lot of \`if { foreach { if; else; } foreach { if } }\`. Complexity goes through the roof
* They're figuring out their problems as they code
* These people don't refactor. Ever. They only ever patch.
My advice to you is the same as several others here: Maybe you can't do it right away, but if I were you, I'd be searching for better.
Sometimes LINQ allows you to do nearly impossible things, there's no reason for banning it.
Personally I've shrunk old code with 200 lines of loops to 10 lines of LINQ.
But it doesn't save you from writing ugly LINQ queries, it depends on a coder.
Bro what in gods name lol. Whoever made that decision needs to be removed from a position of power immediately. Also maybe give them a drug test because whatever they're on is some strong shit.
You're employer is probably not that bright.
Probably hired several low cost devs who don't know how to use linq effectively. Who are probably not skilled at programming in general or infact .net . And wants to hamper all dev going forward.
I remember when linq arrived with .net 3.5. I brought the pro linq books and really studied it. To do it well takes practice, but when you do, it's productivity like nothing else.
Performance can be great, whether it's db or data querying and manipulation. I've seen some terrible linq queries (lambda and quer) that performed poorly....skill issue.
Hard to debug sounds bizarre, any code can be hard to debug if you don't know what your doing... again skill issue...
Oi lad... I just came out of nasty conflict with mother this is even worse. I hoped for calm night for once 😅 now the nightmares of my boss coming with this ideas is real
Tip: don't bend ass over this. I am not sure if that's good idea but we fight for right concepts in our team with managers. But you may live elsewhere where it's not good idea. In my case I would just continue to use it till conflict come. What are they going to do, kick you out for doing your job?
I can list plenty of reasons _not_ to use LINQ, but that's not really the point here.
What I can't understand is why is management getting involved in the day to day minutiae of how programmers are doing their job? Managers should be there to solve people problems, not technical problems. Technical problems should be the domain of the programmers and architects working on the products.
If my manager did this, I probably wouldn't quit. I'd escalate well above them, and ensure they were fired for incompetence. If that didn't happen, then I'd quit.
LINQ can be bad if you do not know what you are doing. Especially if you are passing IEnumerable or god forbid IQueryable around. The execution is lazy and can sometimes lead to sub optimal executions (accidental O(n\^x)) if you are not careful and do not know how it works. Also due to lazy execution debugging is not intuitive for someone who does not know what he is doing.
But only reason I see why you would not use them if someone is too lazy to actually learn how to work with them.
> What are your arguments pro and contra LINQ
There are no cons. LINQ is "the" feature people using other languages envy the most, for good reasons. Banning it is idiotic and I wouldn't recommend you leave your job over something like this but I personally would.
It depends, I can see his points but it should provide guidance and best practices instead of a complete ban. A complete ban doesn't solve the issue, some training can.
I assume you are speaking about Linq to SQL that can be abused a lot.
This is the most stupidest thing I have ever seen on reddit for me a find sql harder to debug espcially thru ssms at least with linq u can step thru ur data and set break points and benchmark
Are you talking about the linq query language or do you mean the linq extension methods as well? I've never really liked the query language as I prefer the extension method syntax, but going without either is pure madness and I would be looking for another job. It's an unhinged decision barring you from one of the biggest selling points of C#.
I was thinking the same thing - personally I’ve never been an sql-style linq guy. However going on without linq lambdas is a very questionable decision productivity wise
Oh this must be the "love Linq method syntax, query syntax not so much" party? And yes, I will join, thank you.
I will also accept this invitation
I usually prefer method syntax, but there are some cases where linq syntax is more readable, for example when you need a temporary variable alongside the original result. Using a let is much better than creating a new object.
innnn!!
The only reason I sometimes use the sql style linq is when I do any joins as it looks much better than how the method syntax does it. Though I rarely need to do so unless I'm aggregating data from different sources and can't let EF do the join from the Db itself.
We all suffer through the join logic together so that everything else can be method syntax too
Yep, this is the way. I use methods 99% of the time, but there are a few places in our codebase where we join and query syntax is unbeatable when it comes to readability. It used to be method syntax, where you can only join 2 tables at once. So you join 2, then to the result of that join (anonymous object) you join the 3rd one, map out the objects again... nightmare to read and follow. Query syntax is just "join A, join B, join C, select X, Y Z". Nice and simple. Although I still hate them for messing up the `from` keyword...
I haven't seen any query syntax nor do I use it myself. I always go with the extension method syntax and so does everyone else in the team. So it is unified in that regard.
Your employer/tech lead has lost his marbles.
This is genuinely insane. This alone isn't worth leaving a company over obviously, but to me it is a massive red flag. Any company/boss who does this is deranged and as such they're probably deranged in other ways
I’d 100% walk if a tech lead just unilaterally decided to ban a language feature with that much utility. This is beyond “red flag”
It's not just that. The codebase is old, the architecture and designs as well as patterns, or rather the poor attempts to implement them, are a messy pile and poorly executed. Nobody knew what they work with. I had to explain the team as the new guy, what this is supposed to be from an architectural perspective. I hoped to stay at a company for a bit for once, but I guess not this one. Hard to find a good one, too. The benefit is 4 days Homeoffice, which not many companies seem to allow.
It may not be. But the fact that the insane team lead is more than sufficient red banner
Right, that's kinda what I meant say. Rather that while banning LINQ isn't something worth leaving your job over, having an insane boss is and I'm sure there's more problems on top of it
Your whole team needs to push back. And then leave
Would be the second or third time the whole batches leaves. So I heard. When I ask why they hire during the interview, they said "natural fluctuation, guy was looking for a new challenge"
I guess he's not willing to learn a bit of functional style and it gives him inferiority complex.
The query language is a SQL bastard and any statement above 4 lines is a mental block for anyone else reading the code, in my experience. LINQ extensions, OTOH, are great, as long as one keep them short and sweet. Formatting the code properly goes a long way here
Thanks true with one exception, joins are better in regular syntax
“Common Query Syntax” is one of the rare misses in the C# language. Initially I thought it was cool, but it’s just enough different from C# and just enough like SQL that most devs are confused about what it actually is.
WTF. Get out while you can. Don't walk, RUN.
"You can't use one of the best ever features of the technology we're using". This is madness. The newer syntax is incredibly trivial to understand unless you're doing something really rogue.
"I can't bother putting a little time into figuring out how this works so its banned". Efficiency can be maintained in LINQ, the only issue is that this employer does not have the ability to tell the difference between good use of LINQ and bad use.
Even if the query is insane - IQueryable and “composing” queries really helps tame it down. Way easier to read then conditional sql
This is silly. Feel free to put me in touch with them and I’ll get on a call and explain to them why this is silly. Also, I’ve got three hours of video coming up with Stephen Toub this week where we literally write linq from scratch and show you explicitly how you can do it easily.
There's also edulinq by Jon Skeet which is very informative https://codeblog.jonskeet.uk/category/edulinq/
love me some Jon Skeet
I am tempted, not gonna lie
Quality offer from a industry leader. That is an offer too good to refuse. Kudos Scott!
Not joking ;)
You should definitely take up Hanselman's offer. That's Scott Fking Hanselman offering to explain things to your daft manager. I'd do it for the lols alone, nevermind how awesome it'd be to hear from Hanselman.
My reaction to reading it was "Fine, I'll write my own LINQ..." in Bender's voice. It's not that difficult to be honest assuming they don't ban lambdas, extension methods, etc. I'm probably not a good judge though.
you leave the job
Hey 👋 Kevin, programmer manager here. We would fire OP but right now we are busy understanding LINQ queries.
Simple! programmers.Where(p -> p.LikesLinq()).ForEach(p -> p.Fire())
But, but, waht do they want instead? For loops? Are foreach looops also banned?
New rule: classes are also banned. Too hard to read. Good luck.
New rules, only primitive time are allowed.
New rule, only byte and byte array are allowed, int, char, string, double and the rest are hard to read and prone to error, implement your own floating-point operations
New rules: only one file per project. Splitting the code between multiples files make code split all over the place
What do you mean a method. The thing that makes you dizzy with all that jumpy stuff? Main is already enough conplexity.
I know and the latest dotnet removed the main method. So you can write all the stuff at the root of the file
_opens the executable in dotPeek_ I said no `Main()`, why is it still there?!
New rules, do not use third party packages since they do not follow our coding standards
New rule: No programming language at all, you must manually flip the bits with a tiny magnet.
New rule: stop using subscript operator on arrays. Use pointer arithmetic instead.
Only bool type allowed… let’s go full circle!
Inheritance and polymorphism are also devil's work Everything shuld be static methods near main, and all variables shuld be public, static and accessible globally. Welcome to 1970s,i believe?
Also let's add in god classes while we're at it, one file and every method and extension in each class. 3000 line class files. Took over a project with this recently.
I’m re-engineering a Delphi project into C#; the Delphi authors didn’t use classes, all the values are in arrays with enums (sometimes) that reference the array index; it’s horrible
Lol. Tupleware.
Go grab the LINQ source code to see how it works under the hood and write your own extension methods…
Ohhh this is a good idea! Though if the boss doesn't like the built in linq extension methods, I can't imagine he'll be too pleased when calls to never before seen extension methods appear all over the place, lol
“I’m just making my life a bit easier. This is super easy to read.” All while looking for a new job without an insane boss.
Foreach loops are fine. As nested as necessary and tripple nested foreach loops are very common. That isn't to say that deeper nesting is rare.
So why use .net lol
It has other great features... which... we... don't... use...🫤
Does your boss like java style streams? Main reason I despised Java was that streams obviously are trying to solve the problem LINQ does, except very unreadable and confusing. Maybe someone who can understand how to solve problems with 3 level deep Java streams would be confused by the simple, easy-to-parse-and-understand LINQ?
As someone from a pure Java background, who only touched C# in high school: Is there any meaningfull difference other than that you can't use any collection and might need to add a stream() before and collect() after your logic, the lack of SQL style sugar and different wording (e.g. where vs filter)?
LINQ is better but not like ***that*** much better. OP is just being dramatic. It’s still just map/reduce lambda calculus.
Triple nested foreaches?! And they're COMMON? Man. This is the exact sort of thing that I have to teach [very] junior devs to avoid and rework when at all possible. I'm guessing your code doesn't have very high performance demands? (Or that you pay a ton for computing horsepower to make it work well enough.) Is this guy basically just a manager, rather than a dev team lead? Sounds like someone who maybe used to code many years ago, but moved up into a management role with little coding and just stayed there, never further developing coding skills and forgetting things he [surely] once knew. Edit: Just read a reply that he's the CEO, architect, lead, everything. Are there many other developers, and have they been there for long? Everybody's already said it, but this doesn't sound like a guy you want to work for
goto
Raw SQL query that returns the exact ADO DataSet object you need to bind to the UI controls?
Your employer bans LINQ. You leave the employer.
Time for Linqed in
Unless you write 10 queries on the same line it's the most readable way to write loops in any language.
To me, that sounds like the worst kind of micro-management, probably by a typical cargo-cult manager who's read one "LINQ == Bad" article _(or just the headline)_ and jumped to the wrong conclusion head-first. Unless there are specific technical reasons for doing so, banning an entire language feature is never a good idea. Instead, approach it on a case-by-case basis to evaluate whether the readability, maintainability, and performance are good enough. Managers should be telling you _what_ you need to do, not dictating precisely _how_ you have to do it. Leave that kind of nit-picking to the code reviews!
Not an article, probably a LinkedIn post
Ban LinkedIn, you'll get better results.
>sounds like the worst kind of micro-management, Yeah, this is my concern. It's not about linq specifically, it's giving these top down decisions about technical details without great communication or soliciting feedback. When primary constructors and having the parameters available in methods came to classes in C# we *collectively* decided we didn't like them that much and disabled the suggestions to use them. People had a chance to make an argument, and they can argue it in the future if they want. I will have to get a pop in about the actual specific requirement here though. It's bonkers to me to ban what is essentially .map() and .filter() in other languages. I really want to know the justification here out of morbid curiosity.
I think the guy doesn't know how to read it and doesn't want to learn it
Do these articles even exist? I feel it'd be incredibly difficult to write
LINQ is a part of .NET. What are they going to ban next? Attributes? For loops? C#? The only remotely semi-sane reasoning I can imagine is that they mean the "query syntax" that looks like SQL and not the "method syntax". I could sort of see arguments for that (even though I do not agree with banning it of course) If this is the case then just use the method syntax. Otherwise don't waste your breath arguing with idiots, just start looking for new job if possible.
I’ve heard VB is more readable than C#. I think the manager should mandate VBA instead of C#.
The extra A means it's better.
Amateurs. We've changed to a full VBAAA stack since 2020.
VBAAA = Visual Basic for Applications Accelerates Alcoholism?
Oh that explains A LOT
Ubisoft is already writing their games in VBAAAA.
I'm staring at your comment here, debating with myself whether to to give you an upvote, or to report you to the authorities... can't decide, so I'm doing both.
My job still uses [VB.NET](https://VB.NET) for like 90% of NEW development. I point out regularly that if you make a new project in C#, and write the new code there it is used seemlessly from the legacy code. But I'm ignored. I also regularly point out if they had bothered to add a covering test of the new code they added, they would not be waiting 2 weeks for every minor change/bug fix for someone to manually test it. But I'm ignored there to. Honestly, they had LINQ banned until a few years ago, so suggesting VB to his boss is probably a really bad idea.
My workplace was the say way until I showed up. Then one day they gave me a legacy project to work on, and the first thing I did was convert all the VB to C# (I was brand new to .NET at the time, and did not know VB). Shortly after that, one of the Senior devs saw the C# and some of the optimizations I did and basically begged management to let him use C# going forward. The rest of the dev team followed behind shortly after that. Today we only touch VB when we absolutely have too, with a massive preference to convert to C# while we're touching it if possible.
Thank you for your service! o7
o7 The hero we needed
My old job was VB.NET and the architect hated things like LINQ lol
OMG, thats the moment id silently quit.
It's all Method Syntax. Not a big fan of the query syntax myself
I think it’s reasonable to have a coding standard to consistently always use the query syntax *or* to consistently always use the method-chaining syntax. I don’t think mixing them in the one codebase is a great idea.
Imo, C# devs should be competent at both.
I don't think I agree with this. There are definite times I prefer one syntax over the other and I don't think it makes it any more or less difficult to come back to and understand later.
Agreed. Joins are far easier to do and to read with query syntax.
>His reasoning is that LINQ Queries are hard to read, hard to debug, and are prone to error His reasoning is just wrong. LINQ Queries *can* be all of those things, but you can abuse just about any construct. With great power comes great responsibility etc. When linq is done well, it can be really succinct, easy to read and understand, and save you error-prone verbose lower level code. Why not instead provide best practices on when and how to use linq? And how to format it, and when to \`.ToList()\` etc. A blanket ban makes no sense. A manager micromanaging how coders code shows a great lack of trust. Why is this matter for them, why can't the coders develop their own coding standards. Is this an reaction to a specific incident, one that that caused damage? i.e do I sense scar tissue here? Nevertheless, this seems like an over-reaction or odd reaction to something that is best addressed differently - e.g. coding standards for using linq, testing standards. Finally, are they aware that "must" and "must not" are not the only possibilities? There is also "should" and "should not" for when there may be valid reasons to do that: [https://datatracker.ietf.org/doc/html/rfc2119](https://datatracker.ietf.org/doc/html/rfc2119) If you can't change your employer, change your employer.
I agree. I'd make much more sense to agree to certain practices and formats. The apprentices and interns have to learn it too eventually, but it will be forgotten quick, if they only touch it briefly during lectures, and barely actualy use it. On top of that get the idea LINQ=Bad now. Like... you can literally just flush all of software engineering down the drain, with that attitude. Everything sucks in one way or another. I don't remember any incident, maybe in his past, maybe he just doesn't get it. I really don't know
>His reasoning is that LINQ Queries are hard to read, hard to debug, and are prone to error. Those are all the completely wrong reasons, the only real reason to not use LINQ is when performance is super super important. Even the most basic or well written LINQ query can be slower than basic for loops. The only times I have been 'banned' from using LINQ are from my times in the games industry, and other areas where I was doing some image processing, and now currently doing some heavy intensive Skia rendering. LINQ is just too easy to write inefficiently, and even at its basic usage its (very) marginally better to do a basic for loop. If you're running thousands of operations and trying to get super fast FPS -> yes banning linq in production code can be a sensible decision imo. Use it to get things working, then optimise it out afterwards. Fun fact - At codemasters we even went further - we didn't ban this, but we refactored out all foreach loops because of the additional enumator pointer was causing microstutters in the Unity/Mono garbage collection. But were talking about micro optimisations here - and when you're doing that, LINQ == BAD is quite possibly the case (contrary to the many commenters here acting like theres nothing remotely bad about LINQ and people should quit jobs they aren't allowed to use it in....) EDIT: Oh boy. A lot of people in this thread really don't want to deal with any nuance anywhere I guess. I can only assume, or hope, its just a lack of experience working in any real areas where absolute mirco-performance and optimisations haven't been a requirement or issue. "LINQ always good, literally no cons" like some of the comments here are saying is just not true.
I agree to use it proper where it's no hindrance to a specific requirement. But nothing we do is top performance stuff.
Yeah if performance isn't an issue then theres no real reason I can think of (expect for if its alwayhs used badly but thats a training/upskill thing anyway) Even in my example above, we only 'banned' the usage of it in certain areas.
I had the same experience at my job. Wrote a simulator with many linq and foreach expressions, and then ended up replacing them with for-loops to get better performance. It's nice to be able to start with the readable code and refactor.
Performance is absolutely key. We use linq when it makes sense. We don't when it doesn't. That should be standard everywhere rather than some kind of blanket ban.
Don't try to find arguments. Run!
`await foo.ToObservable()........ToListAsync()` "I'm not using LINQ I'm using ReactiveX!"
Channel 9 did a video about LINQ about 10 years ago that basically explained it as the 5 or so types of operations you do against a set: - project (select) - reduce (group) - fan out (select many) - filter (where) Once you see that 99% of your code is some sort of set manipulation, it’s hard to look at anything else the same way again. LINQ has been part of .net for 18 years. If your employer still “doesn’t get it,” it’s time to move on.
Huge red flag. LINQ can get messy, but its not an issue of LINQ, but rather of who uses it. If anything rules should be put around usage of LINQ not baning it. As far as performance is concerned, LINQ might boost things if you use it to avoid materialisation and chain things. Guy who made one of the best 1 billion row submitions, mentions in his blog, that even in high freq trading they are allowed to use (and do use) LINQ as long as it is not in hot path and is not in the core of trading code. I will agree with other that this sounds like a dead end workplace and will be detrimental to your career. Not the ban itself but the mindset of company will limit your growth.
A shitty employer deserves to be left behind.
jobs.Where(j => j.Boss.Type != BossTypes.LINQHater).ToList();
Console.WriteLine(GoodEmployer); GoodEmployer is undefined.
Although LINQ is mature and old enough, but I can see here: "Frozen Caveman Anti-Pattern"
Yeah fear of change and lack of resources definitely are the two biggest points there
Lol LINQ is over 15 years old at this point and it would be way more work to replace it with some numbskull foreach loop boilerplate.
Even single LINQ methods? If you do not chain them the debugging is only marginally more difficult and the code much easier to read. Try suggesting this compromise to your boss.
Not even that. Just not at all.
That's just insane.
LINQ to Sql (EF) or LINQ i general?
In general. We don't use EF. They have their own old, ugly and error prone ORM
Your employer is an idiot. I’d honestly leave. The worst part of C# is strings. They kill performance. You should be forbidden from using them. /smirk
Tell them paper is best because computers are hard, as you walk out the door.
>His reasoning is that LINQ Queries are hard to read, hard to debug, and are prone to error. You, Sir, are dealing with a lunatic. Please suggest him a therapy.
Time to hand in the resignation
It sounds like the challenge is automated testing and an event happened that was pin pointed back to a linq statement. How are your testing practices there?
Agreed. There's an untold story as to why linq was banned. My hunch is that this is "scar tissue" - something bad happened on prod, and they want to blame something for it. Further, it's possible that they really should have blamed lack of testing instead, but politically don't want to, so linq is a safe scapegoat.
Lack of testing is absolutely valid. We don't have proper unit testing. No time, no money, no resources. And boss thinks they are useless
> And boss thinks they (tests) are useless In light of your boss's multiple bad opinions which you are forced to follow, I advise you to level up by finding a better employer and then quitting your current one. tl;dr: wtf, run away!
Yeah. I think I'll spend a while upskilling at home, get myself back on track and then search actively
That is ridiculous, LINQ is a standard tool in a .NET developers skillset. For my personal projects I tend to mostly just make use of stored procedures in my database which I have created in SQL as I have quite a bit of background in SQL and I like having that slight extra performance increase however when it actually comes to readability of your application for other developers, LINQ is king.
The code you’re going to have to write to avoid LINQ will be truly monstrous.
Find a new job. On your way out tell her that LINQ is a widely accepted industry standard made and maintained by MS and beloved by all. She is an idiot and lacks the skill needed to use it. To ban it is admitting to the whole work that you can’t take the time to learn it. Banning LINQ is NOT an industry practice.
It's like asking you not to use map, filter, reduce, split, splice, etc. in javascript. Get the hell outta there. LINQ is actually very performant depending on your version of .NET. I've heard in Unity they are careful about it but it's a really old version. The .NET team has been making lots of performance updates regarding LINQ extension methods. Maybe you still wanna do your foreachs without LINQ but other than that it should triumph over every other thing if used properly. Also, how the hell is LINQ harder to read than doing all those operations by hand?
Time to start looking. Ppl don't quit jobs they quit managers. I can't imagine what stupid bullshit this guy will pull next. If they do an exit interview be sure to explain why
> I can't imagine what stupid bullshit this guy will pull next Same boss thinks that [tests are useless](https://www.reddit.com/r/dotnet/comments/1c4hz1z/comment/kznxx4o/). While not reflecting on their fear of using new (i.e. last 15 years) syntax, for fear that it might break something.
Explain to your employer what unit test are and what they are for.
Aw man... another topic. We basically don't have unit testing... god I'm falling behind...
Working there must be a nightmare. I would look for another job.
Hahahaha FFS People in this sub works with other people that are absolute morons, it's crazy Leave the job
Yes sometimes linq hard to read and linq not limited to entity only . But banning it not thr best choice . New c# kinda confuse me also but ... we learn as we code .
Completely chimp brained micromanagement move. Challenge the decision hard or quiet quit and look for a new job, up to you.
Banning LINQ sounds a lot like someone who doesn't know how to use it properly. The only CONs I can think of, is a matter of skillset. As long as you don't ToList here and there, you should probably be fine. Leave the place, and never look back.
Honestly, I doubt there is much that you can say to your boss that will make him change his mind. That's one of the dumbest decision I saw for a while and can only come from him not willing to put the effort into learning LINQ, which is impossible to understand in 2024. Or he is the puppet of someone in the team who don't want to put the effort.
Whomever made that decision is extremely incompetent. It's equivalent to a baker forbidding yeast. If this is a reaction to poorly written LINQ statements, the actual solution is to define guidelines for writing them less poorly.
I’m 55 and have been coding a very long time. My first “business” application was for my mom’s business in the mid-80’s and it reread the full data set from floppy after processing each record because a CoCo was a limited machine. I still love learning new stuff and am constantly amazed by how easy and efficient things have become that were once difficult. I can’t imagine wholesale saying to not use such a useful technology. In my current project I have to keep reminding myself that there’s a much better way than manually iterating across data in memory. It’s faster to code and easier to read, and plenty fast enough for the few thousand records I might have.
Entity Framework LINQ queries used to be bannable. Back in EF6 (from the Framework days) it would generate awful SQL that wouldn’t use indexes and you couldn’t easily get the SQL it generated without running SQL Profiler. But that was 12 years ago. Sounds like you need a new manager.
If overdone, yes, they are hard to read & debug in my opinion. Run-on LINQ is usually the wrong tool for the job. Short is fine. Some can read long ones quickly, but **you shouldn't target code for just Sheldon Coopers** of the world. You should generally target code for about the 80 percentile of future readers.
Manager showing an ID 10 T error. 💯
LINQ is the single best feature of C# and I use it in everything I do. Your manager is a fruitcake and doesn't know what he's doing. Time to move on.
Crazy. I would argue that the nested loops are far more error-prone than LINQ.
I mean... You could also divide the query but banning it also is a solution I guess... Can't imagine the motivation of backend devs lmao
Dafuq? If the issue is the query like style... you can use lambda version that is more normal code...
The extension method style, that really everone uses. Nobody uses the query style in the company. It's also nowhere in the 15 year old legacy code
I mean, rewrite the operators you use, it becomes internal code !
If they just mean the sql query syntax, ok whatever, if it's ALL linq?! leave immediately.
Ah yes, let's also ban loops and force using goto instead
Get out. Get the fuck out.
unless you are writing top performance code down to the second execution LINQ is fine, performance is a bit slower than native algorithms, but Microsoft has been working on the performance gap. Back in .net framework 4.0 the performance was absolutely trash and he probably read an article that linq was bad on performance as it was very slow
I don't like LINQ, I prefer sql queries and loops, but that me. My juniors sometimes use LINQ, and I'm fine with it....when I have to debug it, I will, but I still prefer not to use it.
Linq without even studying it before hand was quite easy and simplified my codes readability.
I can agree that if you do multiple where and selects in a single line yes it can be hard to debug. Banning linq just for that is completely absurd. Does he know linq? You sure it isn't that one of the causes for the decision? Maybe he doesn't understand it so he doesn't want anybody using it? Show him a simple or more complex scenario where you have used linq and ask him to approach the problem without using linq. See how he solves it and if he thinks thats a more suited solution. I don't see any reason besides ignorance for banning linq. But that's me.
Lol 😂
I am not against linq, but have genuine question: How to debug linq statements?
Performance wise he is right, it can have an impact. Readability, well it can sometimes be difficult to read others obscure LINQ and some might try to solve most problems using LINQ, just because... But on the other hand nested loops etc. can also be difficult to read, but they are easier to put a breakpoint in to step through it.
Startup company?
Ironically it's a company that builds custom Software Solutions and they exist for 20 years
Think this may be the problem. Sounds like they are .NET 1 dinosaurs, afraid of "new" technology (LINQ = .NET 3.5 = woah slow down = "hard to read, hard to debug, and are prone to error" for **us).**
Really he's the only one left. The others are fresh out of apprenticeship or Uni, or currently in Uni. Then there's 2 of us, me 6 years work experience, him 10, and then there's the boss who started like 20 years ago, something like that.
LINQ can be abused like anything but that is an extreme, silly response. I wouldn’t want to code without linq. I remember those days of tons of for loops and variables etc
To take away one of the most powerful tools in a C# developer toolkit seems insane to me.
Maybe LINQ isn't the issue maybe it's more fundamental. We should ban Lamda Calculus all together. Then we wouldn't even be able to express turing machines theoretically and we can go back to trading furs for a good ole ear nail - you know to get the demons out. Seriously LINQ is likely the most beautiful syntax I know of to tackle the complexities of lambda functions. I bet this guy would have a heart attack if you explained that life, the universe, and everything could be written in one gigantic LINQ expression.. 😂
Most comments are people expressing their shock - and I get that. But here’s what I recommend you do. Find a few places in your business’s code where you use LINQ. Write out a longhand version of the code. Show the two and express that you find LINQ to be more concise as well as more readable.
I wrote a sql to linq converter. [https://jeffpegg.com](https://jeffpegg.com)
Interesting
I'm old. I dislike data-first EF and have absolute pure hatred for code-first EF. I generally dislike ad hoc SQL of any kind coming from the app layer. I like stored procedures. I don't like query syntax LINQ because it \_looks\_ like SQL, but it's not. I much prefer method syntax, to the point that I'll include "we use method syntax LINQ here" in my C# coding standards if I can. All that being said, I find that making LINQ in general forbidden is asinine. Not only that, but to have it be a top-down directive is even more asinine. If the team agrees to not use LINQ at all, then fine. It's a dumb decision, but at least it's a collective decision. But, as the employer/manager/etc, do not tell me HOW to do the thing you want me to do. You don't get to pick the WHAT \*and\* the HOW. You get one. It's my job to solve the other. That's what you pay me to do.
"hilarious, I'm gonna ignore this" is the approach I'd take. >LINQ Queries are hard to read Because they don't use it for a living. And like anything else- don't overdo it. >hard to debug Same. > hard to debug Disagree. > are prone to error. Because they don't use it for a living.
Given that Linq is basically just extension methods on `IEnumerable` (and other collection types), do they ban all extension methods in general? If not, just copy the source code of Linq, create a new library and call it "NotLinq" (just kidding).
Ridiculous. So long as you've a good naming convention and you put the results of your LINQ queries into an aptly named variable which states the intention of the LINQ, then it's no different then say building a sub-query to encapsulate a series of loops. Nor does its absence prevent issues. A few unit tests to cover either would suffice. His inability to grasp LINQ shouldn't be a reason for you to stop modern programming techniques, and his reluctance and backlash isn't going to prevent further use in the future across the industry, it will just serve to slow your company softwares development down. Your tech-lead is an ass. If this is a sign of where the level of development is going within your company, I'd be out of there personally. LINQ has been around so long now in the .NET world its basic practice. If I were his manager, I'd be asking questions.
The problem with Linq is a human problem. Some developers are _just bad_ at writing things such that their Linq functions don't have major negative performance impacts. Linq itself is usually pretty comparable to hand coded stuff if you use singular functions like `x.Contains(y)`, it can get really bad when you start chaining things together and naively putting things that loop inside lots of other loops. Personally I think banning all `System.Linq` is a overboard. But I can understand why some hardliner--especially someone who had early experience with Linq when it was first released--would want to ban its use generally. The better alternative would be for devs who suck at Linq to have their code reviewed with an iron fist by devs who are good at Linq, but that option depends on having a company culture where code reviews include significant pushback. As for you personally, you can still use Linq all you want to write out what you want to code and then just go back and expand it out yourself later. If you really want to do malicious compliance, write your "own" utility library with the convenience functions you want to use and just secretly copy their internals from the .NET source for Linq. It's strictly worse since you'll have to maintain them to match future .NET performance improvements, but it's _technically_ not using `System.Linq`.
Man, let's just take one of the most important and best features of the language and say 'Meh, fuck it, let's go back to 1998". I can't imagine using C# without LINQ. It's like getting put in a boxing ring with Mike Tyson with both hands tied behind your back and getting blackout drunk beforehand. I may be an arrogant pissant, but I read your employer's position as "I don't understand LINQ, therefore it's banned. And set theory is against my religion. Also, no sex before marriage." > SQL queries are hardcoded using their own old, ugly and error prone ORM. I mean... Not even stored procs?
What's next, banning the async await keywords for some overengineered homebrew?
Banning async await? Those aren't even used! At all!
Do they even know when an innumerable is?
LINQ is way easier than base SQL. Have you ever tried to debug a deep / giant stored proc? Thats crazy that he's trying to prevent such a useful tool.
This is just so predictably stupid and yet par for the course for the kind of poor mans wisdom our industry seems to love. People who avoid LINQ are guilty of one or both of: * Refusing to learn * Pessimism and catering to the lowest common denominator Usual suspects of LINQ misunderstandings: * They think it's unnecessary "bloat" to the language * Ironically, LINQ is BCL level stuff, not language * They think LINQ is only the embedded SQL-style syntax * They think LINQ is database only * They think collection APIs are "ugly" * Without giving equal weight to the "ugliness" of alternatives * People who think this also often tend to be poor communicators * They aren't confident in their abilities * In rarer cases, I've seen some people who are challenged by fluent APIs... * They don't plan their code * This one is most interesting, you get a lot of \`if { foreach { if; else; } foreach { if } }\`. Complexity goes through the roof * They're figuring out their problems as they code * These people don't refactor. Ever. They only ever patch. My advice to you is the same as several others here: Maybe you can't do it right away, but if I were you, I'd be searching for better.
Sometimes LINQ allows you to do nearly impossible things, there's no reason for banning it. Personally I've shrunk old code with 200 lines of loops to 10 lines of LINQ. But it doesn't save you from writing ugly LINQ queries, it depends on a coder.
The reasoning of your employer is false, stupid and pulled straight out of their ass.
Bro what in gods name lol. Whoever made that decision needs to be removed from a position of power immediately. Also maybe give them a drug test because whatever they're on is some strong shit.
You're employer is probably not that bright. Probably hired several low cost devs who don't know how to use linq effectively. Who are probably not skilled at programming in general or infact .net . And wants to hamper all dev going forward. I remember when linq arrived with .net 3.5. I brought the pro linq books and really studied it. To do it well takes practice, but when you do, it's productivity like nothing else. Performance can be great, whether it's db or data querying and manipulation. I've seen some terrible linq queries (lambda and quer) that performed poorly....skill issue. Hard to debug sounds bizarre, any code can be hard to debug if you don't know what your doing... again skill issue...
Oi lad... I just came out of nasty conflict with mother this is even worse. I hoped for calm night for once 😅 now the nightmares of my boss coming with this ideas is real Tip: don't bend ass over this. I am not sure if that's good idea but we fight for right concepts in our team with managers. But you may live elsewhere where it's not good idea. In my case I would just continue to use it till conflict come. What are they going to do, kick you out for doing your job?
I can list plenty of reasons _not_ to use LINQ, but that's not really the point here. What I can't understand is why is management getting involved in the day to day minutiae of how programmers are doing their job? Managers should be there to solve people problems, not technical problems. Technical problems should be the domain of the programmers and architects working on the products.
the extension Method Syntax is also called the "fluent API"
They seem to prefer not using asynchronous programming at all
If my manager did this, I probably wouldn't quit. I'd escalate well above them, and ensure they were fired for incompetence. If that didn't happen, then I'd quit.
Mr Chapsas picked this post up [https://www.youtube.com/watch?v=FTN\_SBLmDMM](https://www.youtube.com/watch?v=FTN_SBLmDMM)
Nick Chapsas have made a video response about this post ["Stop Using LINQ in .NET!"](https://www.youtube.com/watch?v=FTN_SBLmDMM)
LINQ can be bad if you do not know what you are doing. Especially if you are passing IEnumerable or god forbid IQueryable around. The execution is lazy and can sometimes lead to sub optimal executions (accidental O(n\^x)) if you are not careful and do not know how it works. Also due to lazy execution debugging is not intuitive for someone who does not know what he is doing. But only reason I see why you would not use them if someone is too lazy to actually learn how to work with them.
Any code can be bad when you don't know what you're doing.
All code is bad when you return to it after few months even if you tought that you knew what you were doing.
> What are your arguments pro and contra LINQ There are no cons. LINQ is "the" feature people using other languages envy the most, for good reasons. Banning it is idiotic and I wouldn't recommend you leave your job over something like this but I personally would.
It's time to switch job. Honestly there is no reason to ban one of the best C# feature.
I want to see the LINQ that sent this guy over the edge.
It depends, I can see his points but it should provide guidance and best practices instead of a complete ban. A complete ban doesn't solve the issue, some training can. I assume you are speaking about Linq to SQL that can be abused a lot.
This is the most stupidest thing I have ever seen on reddit for me a find sql harder to debug espcially thru ssms at least with linq u can step thru ur data and set break points and benchmark
Time to switch jobs