tags:

views:

159

answers:

4

When working with my .Net 2.0 code base ReSharper continually recommends applying the latest c# 3.0 language features, most notably; convert simple properties into auto-implement properties or declaring local variables as var. Amongst others.

When a new language feature arrives do you go back and religiously apply it across your existing code base or do you leave the code as originally written accepting that if new code is written using new language features there will be inconsistencies across your code?

+5  A: 

If it ain't broke, don't fix it. Of course, if you have confidence in your unit tests, you can give it a whirl, but you shouldn't really go randomly changing code "just because".

Of course - in some cases, simplifying code is a valid reason to make a change - but even something as innocent as switching to an auto-implemented property could break code that makes assumptions and uses reflection to update the fields directly. Or it could break serialization.

Changing to "var" can actually give you a different (more specific) type, which might cause a different method overload to get selected, etc.

So again; it comes down to your confidence in the unit tests.

Other considerations:

  • does the rest of the team understand the new syntax yet?
  • does your project need to support C# 2.0 (for example, some open source projects might want to retain compatibility with C# 2.0).

If neither of these are an issue, you should be OK to use the new features in new code... just be a little cautious before hitting "update all" on old code...

Here's a trivial example of "var" as a breaking change:

    static void Main() {
        using (TextReader reader = File.OpenText("foo.bar")) { // [HERE]
            Write(reader);
        }
    }
    static void Write(TextReader reader) {
        Console.Write(reader.ReadToEnd());
    }
    static void Write(StreamReader reader) {
        throw new NotImplementedException();
    }

Now switch to var reader on the line marked [HERE]...

Marc Gravell
+2  A: 

I would simply maintain the code as I go. Eventually a large portion of the app will have been cleaned or tuned to the new features and improvements. Don't change something for the sake of changing it. If you don't get any performance or stability improvements there is no need to waste time updating code.

C# 3 building on C# 2 and both are quite compatible. Hence each update should be reflected upon.

Alexandre Brisebois
+1  A: 

I leave it until I'm changing that line (or often just lines near it). Then I upgrade. (Sometimes I'll update the whole class or file, once I change one of them)

James Curran
A: 

I leave it be. Besides the fact that it would be alot of work, there's also the issue of is the code really the same or are there side effects of the new feature.

In the specific case of var, the compiler puts the correct type in at compile time anyway, so there's really no benefit.

EDIT: Actually I'm wrong about var not breaking things, so yeah, my original advice stands. If it ain't broke...

Cameron MacFarland
Actually, switching to var can be a breaking change; see my answer for why
Marc Gravell
Agreed. Must remember not to read SO late at night :p
Cameron MacFarland