Yeah, I thought the same.

I now realise the better test of 'var' would be to compare it to how many times it's not used. That is count the times that 'var myClass = new MyClass()' is used v 'MyClass myClass = new MyClass()'. But my regex skills aren't good enough for that and I'm not even sure if you can do it purely in a regex?

Also I imagine that 'var someNumber = 1' is used less that 'int someNumber = 1', but again, I'm not sure how to do the regex? I certainly only use 'var' when the same word is on both sides of the '=', so not in the case of int/double/decimal etc.

I still use var in that scenario, because if you need different types you have to suffix numbers with an identifier anyway:

    var i = 1; //int
    var j = 1f; //float
    var k = 1m; //decimal
    var l = ""; //string
    var m = ''; //char

There are a few more for numeric types:

  var integer = 1;
  var long = 1l;
  var float = 1f;
  var double = 1d;
  var decimal = 1m;
  var unsignedInteger = 1u;
  var unsignedLong = 1ul;

Yeah, I know you can do that, but I can never remember which suffix is which ;-)

Back when I used to work at a large enterprise the use of 'var' was banned in our coding standards.

Using Linq was heavily frowned upon. It took quite a few years before it started to be accepted..

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.

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.

I use it religiously now, so much quicker to program with imo as you don't need to find out the return type. Surprised it's less used than async/await though, which I think MS massively overhypes the usefulness of (and is annoyingly making a lot of classes have async behaviour by default which can result in very weird random hangs).

Although I imagine a significant number of class declarations would contain no var or async/await simply because of their nature.