According to Microsoft’s coding guidelines, you shouldn’t prefix member variables with _ or m_ or any of that. So you have three choices if you follow that guideline:
- Don’t wrap with properties, just use public fields;
- Use camelCaps for the member variable and PascalCaps for the property (Microsoft’s recommendation); or
- Create two distinct names for every single field.
No developer is going to waste time on #3, and since VB.NET doesn’t allow #2, and since your experience has largely been with VB (I don’t mean that negatively, honestly), it explains why you advocate either #1 or the MS-disapproved member prefix.
I eschew the exploitation of case sensitivity most of the time, but it actually kind of makes for field-accessor properties. A maintenance coder does not even need to search for the property declaration to know that, yes, the property is really just a wrapper for some member variable. Unless it isn’t just a wrapper, in which case the naming is totally wrong. And obviously this isn’t a valid convention in VB or other case-insensitive languages.
I think it would be a great idea to be able to use a “property” syntax. Delphi actually has this syntax although it’s not quite the same thing:
SomeProp: Integer read FSomeProp write SetSomeProp;
Where “FSomeProp” is the field name according to Delphi’s naming conventions and SetMyProp is a method. The “write” doesn’t have to be a method, it could also be FSomeProp. The beauty of this is that you don’t actually have to make the stupid “getter” and “setter” methods - you can link both assignments directly to the member variable, which means only one extra line of code. And you don’t even need to write that code - just write the property and Delphi’s class completion will insert the member variable.
As an aside, Delphi (Pascal) is not case sensitive, hence the “F” prefix. I’m not for or against case sensitivity, I’ll use whichever conventions are accepted for the language I’m using at the time.
It’s not perfect but it is a lot less clunky than C#, and I think they really need a better property syntax. It would be especially nice not to have any extra code at all and declare a property/field hybrid like Kevin’s. C# already has this syntax for Events, so why the hell not Properties? Although I’m not sure if it makes sense to completely ditch fields in favour of properties because properties can be non-trivial overhead, and private member data is the most likely data to be used in long loops. People will argue that it’s trivial overhead but it’s also a trivial productivity boost - is it really worth the trade?
As for the distinction between local and member variables, it was a bit of a pain at first, but I’ve taken to using the “this” reference. It just makes sense, especially in constructors where you are literally initializing the member variables through parameters, and thus the parameters ought to have the same names as the member variables so - once again - anybody who reads the constructor can figure out what’s going on.
I think my reply was longer than the original post. Oh well, we are talking about verbosity here!