[henrikschroder]

> Computation should look like computation.

If you follow standard naming practices in C#, properties are distinct from fields, which means they do "look like" computation once you're used to it.

Add null-conditional operators and null-coalescing ones, and you can get code that is overall much more readable and easy to reason about.

[FroshKiller]

If you follow the member design guidelines, you will not have any public instance fields anyway: https://docs.microsoft.com/en-us/dotnet/standard/design-guid...

[MaxBarraclough]

Good point. A language could even mandate such a style, making the ambiguity issue go away entirely.

[henrikschroder]

Yes, and the parentheses of methods obviously work as a compiler-mandated "style" that make it obvious that you're running a method. I know Visual Studio warns you about properties with the wrong casing, and I'm pretty sure you can make the compiler throw errors for those as well, so you could enforce it on a project level at least, even if the language itself doesn't.

But I agree with you on the Kotlin examples in the article. Even though it's been a while since I last did Java, my gut reaction is that it looks wrong, because it looks like I'm directly accessing a field.

So you need a little bit more than just the feature itself, you need something to distinguish them from fields when you're looking at code, or you're gonna run into surprises. Whether that is casing or syntax highlighting or naming conventions, I don't care very much, as long as there's something.

Of course, lack of discipline can screw it up, but you could name the getter for x "setY()", and make it delete the entire filesystem when you call it. You can't guard against stupidity like that...

[MaxBarraclough]

> the parentheses of methods obviously work as a compiler-mandated "style" that make it obvious that you're running a method

The ambiguity is between properties and fields, not between properties and methods. Looking at the style guide, I don't think there's any difference between how public fields and public properties are styled in .Net. [0]

> Whether that is casing or syntax highlighting or naming conventions, I don't care very much, as long as there's something.

Ideally it shouldn't rely on fancy tooling. I'd rather it be clear in the plain text of the source.

> you could name the getter for x "setY()", and make it delete the entire filesystem when you call it. You can't guard against stupidity like that

It's true, we don't yet have a language that prevents poor choice of identifiers.

[0] https://docs.microsoft.com/en-us/dotnet/standard/design-guid...