Expression-bodied properties vs. {get; set;}

Question

When I have Visual Studio 2017 generate properties for me, it will always use the new expression-bodied properties, for example:

private static string username;
internal static string Username { get => username; set => username = value; }

Is there any advantage of using this style over the following or is it just a matter of preference and readability?

internal static string Username { get; set; }

Answer 1

A few advantages that I can see quickly in the second style:

1. You type less.
2. Can be read quickly.
3. Doesn't make reader think that the getter or setter are doing something special.
4. Find All Reference returns fewer results.

Edit

I missed one major problem with the first style. See poke's answer below.

Answer 2

Yes, there is a difference; a big one actually. Your former solution will create an infinite loop because the property getter and setter is referencing itself.

string Username { get => Username; set => Username = value; }

This is strictly equivalent to the following (since it’s just syntactic sugar):

string Username
{
    get
    {
        return Username;
    }
    set
    {
        Username = value;
    }
}

So the getter and setter for the property Username both reference the member Username which is itself. So when you access the member, it will repeatedly call itself forever and never get back a result.

You probably meant to do the following:

string _username;
string Username { get => _username; set => _username = value; }

Now you have a backing field which you reference to actually store the value of the property. This works fine and there is no difference to the more verbose getter and setter syntax. It compiles to the same thing; it’s just that C# 6 allows you to make it a bit simpler here.

The remaining difference is the explicit backing field vs. the backing field that is automatically created when using an auto-property. Whether you want to use auto property depends a bit on your style, but in general, there is no real reason not to use them if you’re going to create the same backing field otherwise manually. Of course, if you are not storing the value in a plain backing field and/or need additional logic, then you of course cannot use auto properties here. But then you probably don’t end up with expression-bodied properties anyway. See also this question on auto properties.

Answer 3

Expression-bodied syntax is convenient to use it in the following cases:

Get or Set only property

public DateTime Date => DateTime.Now;

Methods

public IEnumerable<string> GetData => SomeMethodThatReturnData.Select(x => x.Name);

And constructor with 1 input parameter

public SomeClass(IRepository repository) => _repository = repository;