How should a variable name indicate it's scope (member versus local versus static versus parameter names)?
This is one of the toughest and most hotly contested stylistic topics in C# code design. Styles range from the use of pure Hungarian notation to the lack of any notation of scope at all. It's not an easy problem because the design of the Managed languages leaves us with no obvious solutions. Prefixing variable names clutters the workspace and adds information that may not be particularly useful. Giving no indication of scope may lead to code ambiguity and in the worst case, actual code defects. It's hard to generate a set of categorical rules for naming members -- following one convention may lock you in to a complimentary rule. For example, if I prefix all member variables with 'm', I may feel that to be consistent, I should prefix local variables with an 'l'.
I'll present some common conventions, and my thoughts on them. Hopefully I'll get some good feedback on this from other managed developers. (As an aside, I've been asked if these rules are applicable to C# only, or whether they should be applied to all managed languages. I would answer that these are very C#-centric, but may have application in similar Managed OOPLs. Rigid application of any of these rules may not make sense in something like VB.Net, and certainly won't make sense in Managed C++.)
That's all for now. I'll be posting part's 3 and 4 soon. Part 3 will cover how to stylistically indicate object behavior using varyingly descriptive names. Part 4 will cover grouping by name and styles I've encountered. If you see anything I've missed, send me feedback, and I'll add a section here!