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]
...