Naming Guidelines
Statistically, the largest cost associated with application development has always been maintenance. Before we continue, I want to take a few minutes to talk about naming conventions because choosing a stable and easily understood naming convention will enable you to write code that's easier to read and, therefore, to maintain.
As most of us know, naming conventions are a touchy subject. The issue was easier back when Visual C++ and MFC first came out. I remember facing this question when I was a lead developer of a team at Peachtree Software that was tasked with writing the company's first accounting application in MFC. It was one of those beginning-of-the-project meetings with everyone raring to go and prepared to fight tooth-and-nail over any philosophical point, as opposed to later in the project when people just want to ship the darn product. As developers filed in, you could just sense from the gleam in their eyes and the texts under their arms that these guys were ready to do battle. In the face of what was surely going to be a bloody free-for-all, what did I do? I punted, of course! I stated that because much of MFC development was spent diving into Microsoft's code, we should use the naming conventions Microsoft used in writing MFC. After all, it would be counterproductive to have two naming systems in the source code-one for MFC and one for ours. Of course, the fact that I like Hungarian notation didn't exactly hurt.
However, it's a new day, and we have in C# a new language with a new set of challenges. In this environment, we don't see the Microsoft code. Even so, after many conversations with Microsoft's C# design team, I've found that a standard is evolving. It might end up slightly different than what I present here, but this will at least give you a place to start.