When to Define Your Own Namespaces
In the "Hello, World" application, we used the Console.WriteLine method that's defined in the System namespace. In fact, all .NET types and classes are defined in namespaces. However, we didn't create a namespace for our application, so let's address that issue.
Namespaces are a great way of categorizing your types and classes so as to avoid name collisions. Microsoft places all the .NET class and type definitions in specific namespaces because it wants to make sure that its names don't conflict with the names of anyone using its compilers. However, whether you should use namespaces comes down to one question: will the types and classes you create be used in an environment not controlled by you? In other words, if your code is being used only by members of your own team, you can easily create naming rules such that name collision doesn't occur. However, if you're writing classes that will be used by third-party developers, in which case you don't have any control over naming practices, you should definitely use namespaces. In addition, since Microsoft recommends using your company name as the top-level namespace, I would recommend using namespaces anytime someone else might see your code. Call it free advertising.
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.
