5 ms·

public int X { get; } is more consistent with how properties are declared. Consistency is important. If you care about clean code, here's an even better way

by zer0nes 12y ago

public int X { get; } is more consistent with how properties are declared. Consistency is important. If you care about clean code, here's an even better way public readonly int X; They are not exactly the same but they are equivalent in most cases. In exotic cases where you're required to use auto-getters, adding the brackets wouldn't hurt.

louthy 12y ago
> public int X { get; } is more consistent with how properties are declared. Consistency is important. As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? It's inconsistent and therefore unacceptable right? If everything has to be consistent we wouldn't have LINQ, lambdas, generics, etc. The braces are for scope in C# and all C derivative languages. There is no scope being created here and no requirement for scope. Also there are other places in C# where the scoping braces can be dropped [when there's only a single statement within]: if(foo == 1) { bar(); } Can be written: if(foo == 1) bar(); So I don't see the inconsistency at all if they were to drop the braces. > If you care about clean code, here's an even better way public readonly int X That's what I use. Cue the next round of discussion about fields and properties...
- Arnavion 12y ago
  >As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? They did change the property declaration syntax too. public int X => 5; is the same as public int X { get { return 5; } } This is exactly the same change they made to the method declaration syntax, so I'm not sure what you're complaining about. Of course it isn't identical to public int X { get; } because the latter is assignable in the constructor. But comparing _that_ to methods is apples to oranges since methods aren't assignable.
  - louthy 12y ago
    I think you're quoting me out of context here. I am debating the consistency angle. My argument is that if there is such a drive for consistency (and therefore that's a good reason to keep the braces) then the method syntax wouldn't have changed to drop the braces. So I feel that argument is moot when discussing the reason for keeping the (what I believe to be) ugly syntax of X { get; } = 5; Your example of the computed properties is not the same. I like the computed properties syntax, but unless the properties can be computed from the constructor parameters then you will still need to either use the ugly property syntax, or readonly fields to get the same immutable guarantees. Personally I am fine with using readonly fields, I was only commenting on how the C# team have (in my opinion) missed the opportunity to get rid of some of the unnecessary clutter. I know however many people don't like using readonly fields for various reasons: serialisation, data-binding, interface declarations, etc.

by zer0nes 12y ago

louthy 12y ago

> public int X { get; } is more consistent with how properties are declared. Consistency is important. As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? It's inconsistent and therefore unacceptable right? If everything has to be consistent we wouldn't have LINQ, lambdas, generics, etc. The braces are for scope in C# and all C derivative languages. There is no scope being created here and no requirement for scope. Also there are other places in C# where the scoping braces can be dropped [when there's only a single statement within]: if(foo == 1) { bar(); } Can be written: if(foo == 1) bar(); So I don't see the inconsistency at all if they were to drop the braces. > If you care about clean code, here's an even better way public readonly int X That's what I use. Cue the next round of discussion about fields and properties...

Arnavion 12y ago
>As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? They did change the property declaration syntax too. public int X => 5; is the same as public int X { get { return 5; } } This is exactly the same change they made to the method declaration syntax, so I'm not sure what you're complaining about. Of course it isn't identical to public int X { get; } because the latter is assignable in the constructor. But comparing _that_ to methods is apples to oranges since methods aren't assignable.
- louthy 12y ago
  I think you're quoting me out of context here. I am debating the consistency angle. My argument is that if there is such a drive for consistency (and therefore that's a good reason to keep the braces) then the method syntax wouldn't have changed to drop the braces. So I feel that argument is moot when discussing the reason for keeping the (what I believe to be) ugly syntax of X { get; } = 5; Your example of the computed properties is not the same. I like the computed properties syntax, but unless the properties can be computed from the constructor parameters then you will still need to either use the ugly property syntax, or readonly fields to get the same immutable guarantees. Personally I am fine with using readonly fields, I was only commenting on how the C# team have (in my opinion) missed the opportunity to get rid of some of the unnecessary clutter. I know however many people don't like using readonly fields for various reasons: serialisation, data-binding, interface declarations, etc.