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