This is a bit technical and probably not interesting to non-programmers or those who don't program C#. So, at lunch, I was talking about the use of member variables prefixes, such as m_, in the use of classes. Currently, Microsoft suggests that member variables have no distinction besides using camel case (someVariable) to describe them while my current place prefers m_. Normally, I use camel case, but I encountered a few situations where I want to distinguish special variables from being used internally.

On occasion, I get frustrated with having to put this. (this.someVariable) in front of variable assigning in constructors. One of my former co-workers put this. in front of everything, basically creating scoped code for anything besides local variables. I also know people who use _ (_someVariable) but I don't like that because I miss the _ a fair often.

Now, naming conventions are worthy of a war. Just like Emacs verses vi. A relatively pointless war of personal preferences. I don't honestly care, as long as there is consistency but I'm considering revising my coding guidelines for my own internal projects, so it came up. And, related to that is the one special case where I want to mark an internal variable as needing special code (typically through the Property accessor) which requires additional code instead of referring to the variable directly.

I considered m_ and mp_ to indicate a member variable and processed member variable respectively, but decided I hate underscores. I know I don't need to have something to indicate it, but experience tells me that indicated special rules prevents a good number of bugs.

So, I think I'm going to go with just a simple one: "internal".

private int internalSomeVariable = 0;
public int SomeVariable
{
get { return internalSomeVariable; }
set
{
// magic happens
}
}

I use internally internally processed variables very infrequently, normally with dialog boxes (setting the member property also changes state in the dialog), so I don't want to make it difficult for all variables, but I still want them to be singled out. Normally, a property (which is PascalCase) always has a camel case internal property. I use this. when I have to, mainly for auto-completion.

It isn't the best approach, but I think it is the least impact that sill conforms to most of what Microsoft suggests in coding conventions. Though, I've also seriously considered dropping the "I" prefix for interfaces, but haven't.