19

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; }
Max
  • 327
  • 1
  • 4
  • 16
  • 4
    Crashing your program with this site's name has no conceivable advantage. – Hans Passant May 18 '17 at 10:24
  • 1
    How are you making Visual Studio generate recursive properties? – stuartd May 18 '17 at 10:24
  • Ha, sorry. Should be better now. – Max May 18 '17 at 10:36
  • 1
    Since you fixed the recursive reference now, this is basically just a duplicate of when to use auto properties. And as for the expression-bodied property part, it would be a duplicate of [when to use those](http://stackoverflow.com/q/28411335/216074). – poke May 18 '17 at 10:39
  • Sorry if I wasn't clear: My question was rather if one could basically just forget about {get; set;} and consistently use expression-bodied properties or if there was a strong reason not to (e.g. a difference in performance.) I was aware of specific cases where expression-bodied properties are more convenient (e.g. if you only need a getter.) That question has now been answered. Thank you! – Max May 18 '17 at 10:44
  • I don't see how this is a duplicate as shown. They are completely different questions that just happen to be about C# properties. – StayOnTarget Jan 28 '21 at 15:48

3 Answers3

10

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;
Sergey
  • 261
  • 1
  • 4
  • 2
    Of your three examples, only one is an expression-bodied *property*. – poke May 18 '17 at 10:28
  • Was looking up information regarding expression bodied usage, and noticed your GetData method did not have parentheses. Is there a c# reference you can point me to that will help me understand this? – James Lee May 08 '19 at 07:00
  • @JamesLee It's an expression-bodied read-only (get-only) property – Dave Cousineau Jul 21 '19 at 21:49
8

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.

Community
  • 1
  • 1
poke
  • 307,619
  • 61
  • 472
  • 533
4

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.

dotNET
  • 28,678
  • 19
  • 120
  • 206
  • *“Expression evaulator is not triggered by the compiler.”* – What do you mean with that? – poke May 18 '17 at 10:26
  • 1
    @poke: The C# compiler needs to evaluate the body of getter (as it could have a complex expression too). For automatic properties, the compiler should be damn sure there is no need to do that. – dotNET May 18 '17 at 10:30
  • 1
    Though I must admit I missed the mega difference you pointed out. Maybe I was under the wrong impression because just today (in another SO post) I learned that automatic getter-only properties can now be assigned to in the constructor. Obviously these are two different things. – dotNET May 18 '17 at 10:32
  • But that’s true for *every* single character of code. That’s what the compiler does. Your wording “expression evaluator” makes it sound as if this involves [runtime expressions](https://msdn.microsoft.com/en-us/library/system.linq.expressions.expression.aspx). – poke May 18 '17 at 10:32
  • Correct and that's why I explicitly mentioned the compiler, not runtime. – dotNET May 18 '17 at 10:34
  • It’s just that there is not really a difference. The compiler runs anyway for all of the code. This is kind of included in your first reason: The compiler has less to compile if you write less code. – poke May 18 '17 at 10:37