>>Interesting that all three of us tend to use hungarian notation for UI controls - and your point re: Intellisense is a good one. Not sure I go along with the 'm_' part though (definitely smacks of the VFP fieldname/variable name connotation) :-}
>
>Here's why I use "m_" for private/protected members that I intend to expose as properties:
>
>1) I got used to doing that in the old 1.1 days, before "automatic" properties came along. And, to be honest, I haven't really "adopted" automatic properties much because I don't like to "mix-and-match" the two syntaxes. Sure, they're convenient for when you have nothing in your getters/setters, but if you do then you have to revert to using the original syntax.
I'm quite happy using them - code looks cleaner. But, since the compiler creates it's own private variable under the hood I suspect that defining your own and accessing that directly within the class will be more efficient than always having to go thru the public property?
>
>2) I don't like the alternative, which is using casing. Too hard to make the distinction between member and property that way (IMHO).
>
>private bool isOK;
>public bool IsOK { get {return isOK;} set {isOK = value;}}
You probably picked an example that shows the approach in its worst light - but I know what you mean. That said it is the method I use (where it's up to me)
>
>Oh, and the other alternative I see people using is even worse, IMHO ... _IsOK and IsOK. yuk!
In the same way that 'm_' derives from VFP'ers I think that is a carry-over from C++'ers :-}
I can be comfortable with that if ness....
>
>~~Bonnie
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only