19

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?

Improve this question

10 Answers 10

Reset to default
20

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

The class library design guidelines only specify API guidelines, but don't actually specify file organization guidelines.
They are all about how to design your API, but leave private, implementation details (including file structure) completely out.
That's true.. I should have made clear that I intended my answer to supplement the other good answers already here.
13

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.

Improve this answer

4 Comments

I do break the rule for very small types. For example, I've often created an "Enums.class", which contains multiple enum types.
@Brian S: I used to do that too, but now that I'm managing a larger scale project with multiple developers in multiple locations, I do a separate file per type, including simple enums. That being said, I don't think there's anything wrong with having "enums.cs" and similar, but I've found it's saved me headaches over time to keep them separate.
Personally, I feel that the more the API is changing, the more important it is to separate, as well. When you have 5 enums in one file, it's easy to have a refactor job leave in a potentially unused enum, etc...
I agree with what you said about organizing the classes to match the namespace, and in fact, Visual Studio will help you -- If you create a folder below your project (in Solution Explorer), and then you add a new class within that folder, notice that VS will have automatically included the folder name in your namespace (it becomes "yourdefaultnamespace.YourFolderName").
4

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.

Improve this answer

5 Comments

In C#, the namespace automatically gets appended with the name of the folder.
@Steven - you mean, "In Visual Studio" instead of "In C#".
Do I? I don't remember the namespace/folder feature the last time I did VC++, but then again, it was a small project. I can't say one way or the other about VB, because I try to avoid it. Haven't done enough F# to know, either. But if you say it's a VS feature, then ok.
VS initialize the namespace according to the directory structure but you can change it whenever.
In VS id the project is a Web Application Project for my understanding namespace is organized just according to the directory structure
2

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.

Improve this answer

Comments

2

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.

Improve this answer

1 Comment

Yeah, I agree with VS 2010 new features and Pro Power Tools extension it's not that important how physically you organize your files. More important is the object oriented architecture of your classes.
1

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.

Improve this answer

Comments

0

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.

Improve this answer

1 Comment

if you can actually break a class apart into functionally separate sections, there's a good chance you should actually refactor the class into separate classes.
0

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.

Improve this answer

Comments

0

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.

Improve this answer

Comments

0

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.