Organizing classes

You will notice that the hallmark of a clean project is that it will have well-organized classes. And folders will be used to group classes that belong together. Further, the classes in the folders will be enclosed within namespaces that match the assembly name and folder structure.

Each interface, class, struct, and enum should have its own source file in the correct namespace. Source files should be logically grouped together in the appropriate folders and the namespaces for the source files should match the assembly name and folder structure. The following screenshot demonstrates a clean folder and file structure:

When thinking about your namespaces, it is a good idea to follow the Pascal casing sequence of company name, product name, technology name, and then plural names for components separated by spaces. See the following for an example:

FakeCompany.Product.Wpf.Feature.Subnamespace {} // Product, technology and feature specific.

The reason for starting with the company name is that it helps to avoid namespace classes. So, if Microsoft and FakeCompany both have a namespace called System, which System you desire to use can be differentiated by the company name.

Next, any items of code that are able to be reused in multiple projects are best placed in separate assemblies that can be accessed by multiple projects:

FakeCompany.Wpf.Feature.Subnamespace {} /* Technology and feature specific. Can be used across multiple products. */

When using tests in your code, such as when doing Test-Driven Development (TDD), it is always best to keep your test classes in separate assemblies. Test assemblies should always be given the name of the assembly they are testing with the namespace Tests appended to the end of the assembly name:

FakeCompany.Core.Feature {} /* Technology agnostic and feature specific. Can be used across multiple products. */

You should never put tests for different assemblies in the same test assembly as each other. Always keep them separate.

In addition, the namespace and type should not use the same name as this can produce compiler conflicts. When pluralizing namespaces, you can forego pluralizing for company names, product names, and acronyms.

To summarize, here are the rules to keep in mind when organizing classes:

• Follow the Pascal casing sequence of company name, product name, technology name, and plural names for components separated by spaces.
• Place reusable items of code in separate assemblies.
• Don't use the same name for the namespace and type.
• Don't pluralize company and product names and acronyms.

We'll move on to the responsibility of classes.