1

C# 6 is here for a while now and brings with it some syntactic sugar that Resharper is kind enough to highlight and recommend that I "migrate to". Should I apply these fixes automatically to the entire code base and commit? Even though this question can apply to any new feature in the language, the main ones I'm considering applying are:

  • Use string interpolation instead of string.ToString
  • Change property from get {...} to expression body ( => )
  • Use null propagation
  • Make auto-property get-only

What if this is hundreds of changes? What if it's thousands?

Carl Manaster
  • 4,173
  • 18
  • 31
ytoledano
  • 281
  • 2
  • 9

3 Answers3

3

If you were talking about manual refactoring to bring your code up to "C# 6.0 standard", I would heavily vote against refactoring parts of your code in areas you are not currently working with. That would bring only a minimal benefit for a certain risk of breaking things unintentionally.

However, you are talking about an automated migration. In such a situation, you can consider letting your refactoring tool apply the steps if you first check the following preconditions:

  • the manual effort is really small

  • everyone on your team knows the new language features, at least to the degree that he/she can read and understand them

  • you trust your refactoring tool that it does not break anything when applying those patches (and even then, you should have enough automated tests in place to check this on your own)

  • the result of the automatic refactoring is really better readable, and you do not have to edit the result manually to reestablish readability.

  • the new features you want to use from C#6.0 do not enforce an unwanted update to a newer .NET framework version you might not be ready to use yet

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
1

It depends.

Not all c# 6 features/uses are available in lower .NET versions (see https://stackoverflow.com/questions/28921701/does-c-sharp-6-0-work-for-net-4-0). If your consumers can't move to the latest and greatest libraries, don't update.

Does your team know the new features? If not, you should maybe do some sort of training before dumping everything in source control.

After that it depends on if your team thinks the syntactic sugar adds to readability. I would probably change a few classes and let your team compare - erring towards the new syntax since people will find new things less readable by default.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • Actually, the answers in the link you gave say "most of the C#6.0 features *can* be used with older framework versions". And though I did not try it out, the bullet points from the question do not look like they need more than the new compiler (but I am not sure, changed my own answer accordingly) – Doc Brown Aug 29 '15 at 05:32
  • @DocBrown - my reading was that pretty much all of the _features_ work with older versions, but not all of the intermediary types you might want to use are available in older versions. – Telastyn Aug 29 '15 at 13:03
0

No. You shouldn't. At least, I sure wouldn't hit that "Fix all the things" button.

I love Resharper, but it doesn't always make the best decisions. If it did, it wouldn't have given us the ability to ignore warnings/suggestions with a comment. The fact is, sometimes those refactorings lead to less readable code and, in a few instances, can break things. (I've had some issues with COM Interop code and ReSharper suggestions in the past.)

So, if you are going to hit that big red button, you had better have a darn good suite of tests in place.

That's not saying that you shouldn't do this at all, but I personally would take the time to check and apply the refactorings myself. Perhaps as you're working on a file, or maybe take a few hours to clean up the whole project. Either way, a person needs to review these changes. Don't just let the machine make decisions for you. If I've learned anything as a programmer, it's that the machine isn't always right and all code has bugs. Even code from the wonderful folks at JetBrains.

Related: Does Visual Studio Rot the Mind?

RubberDuck
  • 8,911
  • 5
  • 35
  • 44