What's the point of not using stable language features? I don't get it.

I've (unfortunately) had to work with this rule before. The justification was that it makes the code more readable.

I can understand banning SQL style linq and allowing only functional style, but I guess that's more of a personal preference.

I used to work in a company with a similar policy. Never got a satisfactory answer, I think there's just lots of FUD around any language feature that looks different than what people are used to.

Neither did I.

goto is a stable language feature.

While it shouldn’t be banned, it should be used appropriately. We have some areas of our project that communicate with hardware where we cannot use it because of the performance hit.

Why on earth? It is resolved by the compiler, there is absolutely no performance difference between using var and explicitly specifying the type.

undoubtedly that person was talking about LINQ and not var usage

Undoubtedly he didn't read properly then. The banned feature was var, linq was just heavily frowned upon.

Or possibly confusing "var" and "dynamic"?

Yes, LINQ not var.

Well, that on the other hand does indeed make sense, depending on the context. The only question there could be if it's a good idea to use a garbage collected language to directly[1] interact with hardware.

[1]: Well, at least directly enough for LINQ performance to be a problem.

We're not real time, but we do have some time constraints.

Yes, all this was kicked around and argued about.

Yeah, I agree. You can make some seriously shitty unreadable code using LINQ just to look smart. But that's what code reviews are there for.

I agree. That, and not using LINQ often enough doesn't resolve that problem per se. Rethinking the problem (or the way you attempt to solve it) might very well improve the code much more.

One of Kevlin Henney's talks references a really neat quote by Poul Anderson on this subject:

> I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated.

Sometimes ReSharper makes some seriously wild, unreadable suggestions for converting code to Linq.

Yeah, but IMO after Roslyn I don't see the benefit of ReSharper, definitely not for the 100 dollar price per year.

That happened right when I started a new job so I haven't touched it that much. R# used to be absolutely essential though.

Are you talking about "var"? Because that shouldn't affect your performance, this generates equal IL code:

var x = 10;

int x = 10;

Yesterday a colleague wanted to compile _and deploy_ code. Checked it out. It .. failed to compile. Sure enough, he fixed it (and checked the change in) before deploying it (test env, thank god).

The code was generating some JSON using Linq and created JSON properties: new JsonObject(LinqExpressionHere)

The name for the property was defined as

$"SomePrefix_{x.Name}"

which he helpfully changed to

"SomePrefix_{x.Name}"

which then compiled, but crashed in the test environment because of - surprise - duplicate attributes..

I just did this in my code! Ported a ton of PHP to C# and forgot to add $ to the front of strings. A compiler warning would be nice for this.

> At one point we were also strongly encouraged to place a #region around every single method! I never understood why, and luckily that one did get dropped

Shudder!!

Especially since VS has plugins (or maybe it's built-in?) that will let you fold/hide individual methods, if you really want to do that!

FYI: It's built-in.