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