How to organize C# classes

Is there a general practice when it comes to how to organize your classes in C#? Should there only be one generic class per .cs file? I see that I have Form1.cs which includes all of the classes relevant to "Form1". However I could create a file named Misc.cs which includes开发者_运维技巧 all misc classes. Not sure which way to go so everything stays organized.

Or should I organize them a specific way? For example, I am accessing a MySQL database, so i'm creating a MySQL wrapper which I will store in MysqlWrapper.cs and name the class to match it. Should I create a new .cs for each class I create?

Or should I combine only the ones that use similar "using" namespaces such as System.Text; using System.Windows.Forms; etc?

Edit - this answer is meant to supplement the good answers that others have already posted.

Everyone else seems to be answering specifics. I'm thinking you're going to have more "best practices" design questions.

The official guidelines can be found here: http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx

In particular, dig into the Naming guidelines, and then into the Namespace Naming guidelines and Class Naming guidelines.

And, as others have mentioned, please, one class per file. It makes things easier on the poor maintenance developer who will follow you.

Typically, I create a separate .cs file per class. In addition, I organize the files to match the class namespace.

As the projects get much larger, this simplifies organization, as you always know where to find a class within the project. This becomes more important as more people are working on the solution, as well. One class per file also can be beneficial since the folder structure gives you a sense of a namespace's complexity, which has helped me realize when I need to split namespaces because they've gotten too complex.

I see that I have Form1.cs which includes all of the classes relevant to "Form1".

Instead of organizing this way, I'd recommend separating these into separate files. If you have quite a few classes relating to a specific operation (performed by, or accessed via, Form1), I'd consider putting these into their own namespace. I'd also strongly recommend renaming "Form1" to something more meaningful, such as "EmployeeForm". This will make it easier to understand and maintain your code going forward.

One class per file is generally accepted. Some classes are spread across multiple files using the "partial" keyword. My folder structure loosely matches the namespace structure.

I don't strictly follow a one-class-per-file rule. If I'm dealing with a very large class with lots of code, I might give it its own file,. Generally, though, I don't have a problem with keeping multiple classes in the same file as long as they are related to one another in a logical way. This tends to work best with small classes, but may not be the best idea for large ones.

I might get flogged for saying this, but at least in Visual Studio, it's probably not as important an issue as it used to be.

Most of my files only have one class each, but for things like trivial enums and simple storage classes used only by one other class, I just put them in the same file as the primary class. Otherwise if I want to use the same class somewhere else, I'd be moving multiple files and trying to guess which ones I need.

You can right click an identifier and click Go To Definition to navigate to it, you can hit ctrl+comma to search, or you can use the Class View.

I do group related .cs files into folders -- that sort of bigger-picture thing seems a bit more important. I also make sure the folder names always match the namespace, i.e. I keep the default namespaces that Visual Studio gives when you create a new class file in a folder.

As a general rule, your code is more maintainable (easier for other people to read) if you have one type per file. (class/struct/enum).

However, with partial classes, I will sometimes actually break large classes into multiple files, based on major sections of functionality. If a class has private nested types, I almost always put those nested types in separate files, as well.

I normally have one class per file. The only exception to that might be if a class has a private nested class and I would normally keep that within the same file rather than splitting it out to a different one using the partial keyword. This way I find things easier to locate.

A few principles are all you need:

Maintainability: It should be easy to keep the project up-to-date and fix bugs. Questions: Will it take ages to find a given class/function? If there's a bug, is it likely to occur where the programmer (who won't necessarily be the writer) will look?

Complexity: It should be clear what the program does. Sometimes splitting it up helps. Sometimes keeping things together helps. Questions: Will someone be confused when they look at it? Will they wonder what all the parts are?

It's really just common sense. Also, note that certain IDE tools will allow you to leave things in a messy state and still be able to find stuff (reference finders for instance). You have to decide what level of mess is acceptable, and when it's time to refactor.

You shouldn't combine classes that use similar "using" namespaces in a file, because, if you have to change the implementation of a class you have to move classes to other files.

I keep one file per class, because is very useful with source control systems. Besides, i avoid as much as possible partial classes. If a class is too big, there is something wrong in the design.

I also sometimes combine similar class files into one branch in VS.

For example - if you have 3 files : Message.xaml, Message.xaml.cs, MessageButton.cs, MessageImage.cs, MessageResult.cs.

Message.xaml.cs already will be shown inside the first file's hierarchy. You can also add others, simply by editing project's file using notepad. You only need to add

   <DependentUpon> </DependentUpon>

tags where it's needed.

I don't know if there is any extension for VS to do that in a lot easier way.

And here is one thing. Although that will help you to organize your files in a project, you won't be able to rename your class simply by clicking twice on the filename in VS.