I am reorganizing my source files into a single solution with a single project, due to various reasons:
a paranoic configured antivirus software;
Advices on partitioning code through .NET assemblies
Control component dependencies to gain clean architecture
Benefit from the C# and VB.NET compilers perf
This leaves me with many namespaces, which are splitted across multiple files. So far, I am using this convention: given the namespace Company.Project.A, the files are named A.f1.cs, A.f2.cs and so on, and the Company.Project.B namespace is splitted across B.f1.cs, B.f2.cs, etc.
Given the single project restriction, are there any better ways to organize multiple files in multiple namespaces?
Yes - use folders.
If you create a folder within a project, new classes within that folder will automatically use the folder name as the basis for the namespace.
For instance, if you have a project with a default namespace of "Company.Project" and a folder "Foo" containing "Bar.cs" you'll end up with:
using System; // Etc
namespace Company.Project.Foo
{
class Bar
{
}
}
So the solution is right here. It's Folders. But it's sometimes tricky. First of all it's kind of a good idea to have one file per class. If you will pack several classes into one file - you'll have problems with finding them with time.
Second thing about folders - if you will click on a folder and choose for example "Add -> New Item", this item will be put into selected folder. But watch out! If you will move files between folders, namespaces are not updated.
It's common source of messing project. Just after a while you can end up with a project where you have neat organized folder and files, but not reflecting namespaces. So for example, if you have class MyClass in folder MyFolder make sure, your namespace for this class is something like MyApp.MyFolder and not some old rubbish.
So If you will not pack classes into one file and watch if classes namespaces reflect folder hierarchy - you're on the good road to make you project very easy to read and navigate.
100% agree with Jon Skeet.
To gain more overview at the folder level we're creating folders breaking the namespace structure by prefixing them with an underscore.
Related
When I put a class file inside a folder, Resharper suggest me to update the namespace. So if I have the file Classes/Game.cs (Class), it will suggest the namespace MyApplication.Classes.
The problem is that I have a subfolder called Game too, that have components for the Game class. And it is confliting with namespaces. For instance:
/Classes/Game.cs MyApplication.Classes.{Game}
/Classes/Game/Version.cs MyApplication.Classes.Game.{Version}
What is the best method to turn around that?
Currently I'm organizing like that:
/Classes/Game/Game.cs MyApplication.Classes.Game.{Class}
/Classes/Game/Player.cs MyApplication.Classes.Game.{Player}
/Classes/Game/Version/Version.cs MyApplication.Classes.Game.Version.{Class}
/Classes/Game/Version/History.cs MyApplication.Classes.Game.Version.{History}
So note that I rename the "main" class to Class to avoid conflict, but I keep a more accurate name in the filename. But it is ugly, not?
First of all, a folder named "Classes" doesn't seem particularly helpful - everything is a class after all and this doesn't seem to give you any useful information.
If you wish to keep this naming scheme, then there are two options. The first is to disable Resharper's recommendations - or at least tell R# to treat them as Hints, rather than Warnings.
The second is to give your folder a name that isn't a valid namespace declaration. This will make R# stop suggesting it as a valid namespace. The format I've most often seen and used is to use square brackets around the name. So you have a folder hierarchy like this:
/Classes/Game.cs
/Classes/[Game]/Version.cs
etc. In this case, R# will suggest "MyApplication.Classes" as the namespace for both the Game and Version classes.
Start with this answer to NET: Best Practices/guidelines for dividing namespaces between files?
While every project, even every game, is going to vary as far as structure goes there are a few things that help.
The first thing you should ask is how large of a project this is going to be. If you don't know, start with everything in the root namespace of your project until you figure it out, and only then refactor. Don't waste time organizing when you could be learning, because chances are you either won't need it, or will need to radically change it once you do figure it out.
Once you know that your project is going to be large enough to require lots of namespace, you should also know what kind of structure it needs. If it's entity-component oriented, as most large games are now, you'll probably want to use a folder/namespace structure like
MyProjectName # System classes, like Game1
.Components # Base component definitions
.Controllers
.Physics
.Renderers
.Entities # Base entity definition and player entity
.Enemies
.Powerups
...
It also helps to work on other people's code. You'll learn a lot about organization from trying to locate functionality in unfamiliar code.
My strategy for organizing files is to put them not only inside of namespaces but often in subfolders that don't act as a namespace but help to organize files. I prefix such folders with an underscore _. If you're using R# you should set the folder property Namespace Provider to false. Also remember to remove the _Folder from the namespace if you add new file because Visual Studio automatically adds it.
Here's an example:
MyProject
Properties
References
_Impl
App.config
package.config
First I put the entire implementation inside the _Impl folder because I don't like files that are scattered all around the project.
Next in the _Impl folder I may use more underscore _ folders if I see no reason to create a new namespace but it would make sense to put the files together like _Exceptions or _Enums or _Attributes:
MyProject
Properties
References
_Impl
_Attributes
MyAttribute.cs
_Exceptions
MyExtpion.cs
MyAnotherException.cs
_Extensions
MyExtensions1.cs
MyExtensions2.cs
SomeClass.cs
SomeOtherClass.cs
App.config
package.config
As namespaces the underscore _ folders wouldn't make much sense but they allow to keep files together for organizational purposes.
Otherwise I would look something like this:
MyProject
Properties
References
MyAttribute.cs
MyExtpion.cs
MyAnotherException.cs
App.config
package.config
SomeClass.cs
SomeOtherClass.cs
In MyProject.Test with unit test I also use this system:
MyProject.Tests
Properties
References
_Impl // only tests
_Attributes
MyAttributeTests.cs
_Exceptions
MyExtpionTests.cs
MyAnotherExceptionTests.cs
SomeClassTests.cs
SomeOtherClassTests.cs
_TestHelpers // here I'll put any supporting classes
SomeTestHelper.
App.config
package.config
Task: reuse C# code in different projects but without project referencing (don’t want extra dll/references just because of a small utility class).
There’re 4 projects, one of them contains utility class which is currently source-code-linked by other 3 projects.
Problem: once one of the projects starts referencing one of others (for some other needs), the compiler starts complaining (obviously) that there’s the same class (with the same namespace) in these projects.
Are there any solutions other than to move the class to separate project or to make 4 copies of the class for each project and maintain them separately?
I wonder is there a way to source link files so that the class inside a file gets project-specific unique namespace…
I wonder is there a way to source link files so that the class inside a file gets project-specific unique namespace…
Well you could use preprocessor directives:
#if PROJECT_FOO
namespace Foo
#elif PROJECT_BAR
namespace Bar
#elif PROJECT_BAZ
namespace Baz
#endif
... and then link the file into each project, defining appropriate symbols in the project properties.
But I would thoroughly recommend against it. It's horrible, and it's certainly not how C# was designed to be written.
Just break it out into a separate project - you're bound to find you want more and more code like this anyway.
To the question:
"Are there any solutions other than to move the class to separate project or to make 4 copies of the class for each project and maintain them separately?"
The short answer is: no, there isn't. Or at least, there is no elegant way of doing that.
The right way is indeed to make it part of a referenced project. But you don't have to make a project that will contain JUST that utility class! Instead, make it a project holding multiple simple utilities with as little dependencies as possible and share it across your solutions. Much easier and cleaner this way.
I find that sometimes I have the need to have multiple namespaces in a project I'm working on - are there any problems that may arise from having multiple namespaces in the same project?
The alternative is obviously having multiple projects (per namespace) in the Solution.
Yes, it's fine. Often my namespaces align to the folder structure of the project. So the top-level namespace might be the same for the whole project, but there would be multiple sub-namespaces.
The purposes of namespaces are (1) organization and (2) avoiding naming collisions, not necessarily in that order. Whereas, separating things into multiple projects is more because you want multiple binaries or you want to share code between multiple solutions. These are somewhat orthogonal concerns.
Yes many classes to a single namespace. Many namespaces in a project is totally fine. It is cosmetic.
The answer to this question, without getting into best practices, is that there won't be any technical problems from using multiple namespaces in one project.
However, visual studio only supports one base namespace, which is located in the project properties (right click properties in solution explorer on the project itself) and any time you create a new file, it will be created with this default namespace (if on root), or the default namespace plus whichever folder structure you have.
Not a problem per se, but you'll need to manually check each new C# file you add to the project and change the namespace accordingly if that particular file will not be using the default namespace for the project.
I have an ASP.NET application with three areas. In the root of the application is a Models folder containing a hodgepodge of classes, including two DataContexts, some Repository classes, some ViewModel classes, some helper classes, and some business logic classes.
I'd like to create subfolders for each of these subcategories and move the associated files into the appropriate subfolder. However, I am noticing that this is breaking things. For example, if I move one of the DataContexts to a DataContext subfolder in the Models folder, I find that the code in the repositories can no longer see the DataContext type.
Which must mean that the Models folder has special meaning to the system. What am I missing here? Is there some way to "sensitize" the subfolders so that the other code can still see the implemented classes and namespaces? Or am I going about this the wrong way?
Probably a namespacing issue? The model folder has no special meaning.
The ASP.NET MVC team has said something like before:
"The only reason the model folder exists is because people kept asking us where to put our model classes" ;)
When you drag and drop your files and folder, it will move the the files, but the namespaces are not updated, thus your code will break. One way is to create new file/folder and copy your code - which is a bit tedious but right way.
Another way is to use Resharper - Ctrl+Shift R, which lets you move the file and also updates the namespaces and your code will not break.
I am finding a faster way to do the same without Resharper, and when I do I will update my answer. Hope this helps!
Taking my first steps in C# I came across this post...
in VS 2019 if you refactor->move the class file you have options to move to another location
Should the folders in a solution match the namespace?
In one of my teams projects, we have a class library that has many sub-folders in the project.
Project Name and Namespace: MyCompany.Project.Section.
Within this project, there are several folders that match the namespace section:
Folder Vehicles has classes in the MyCompany.Project.Section.Vehicles namespace
Folder Clothing has classes in theMyCompany.Project.Section.Clothing namespace
etc.
Inside this same project, is another rogue folder
Folder BusinessObjects has classes in the MyCompany.Project.Section namespace
There are a few cases like this where folders are made for "organizational convenience".
My question is: What's the standard? In class libraries do the folders usually match the namespace structure or is it a mixed bag?
Also, note that if you use the built-in templates to add classes to a folder, it will by default be put in a namespace that reflects the folder hierarchy.
The classes will be easier to find and that alone should be reasons good enough.
The rules we follow are:
Project/assembly name is the same as the root namespace, except for the .dll ending
Only exception to the above rule is a project with a .Core ending, the .Core is stripped off
Folders equals namespaces
One type per file (class, struct, enum, delegate, etc.) makes it easy to find the right file
No.
I've tried both methods on small and large projects, both with single (me) and a team of developers.
I found the simplest and most productive route was to have a single namespace per project and all classes go into that namespace. You are then free to put the class files into whatever project folders you want. There is no messing about adding using statements at the top of files all the time as there is just a single namespace.
It is important to organize source files into folders and in my opinion that's all folders should be used for. Requiring that these folders also map to namespaces is unnecessary, creates more work, and I found was actually harmful to organization because the added burden encourages disorganization.
Take this FxCop warning for example:
CA1020: Avoid namespaces with few types
cause: A namespace other than the global namespace contains fewer than five types
https://msdn.microsoft.com/en-gb/library/ms182130.aspx
This warning encourages the dumping of new files into a generic Project.General folder, or even the project root until you have four similar classes to justify creating a new folder. Will that ever happen?
Finding Files
The accepted answer says "The classes will be easier to find and that alone should be reasons good enough."
I suspect the answer is referring to having multiple namespaces in a project which don't map to the folder structure, rather than what I am suggesting which is a project with a single namespace.
In any case while you can't determine which folder a class file is in from the namespace, you can find it by using Go To Definition or the search solution explorer box in Visual Studio. Also this isn't really a big issue in my opinion. I don't expend even 0.1% of my development time on the problem of finding files to justify optimizing it.
Name clashes
Sure creating multiple namespaces allows project to have two classes with the same name. But is that really a good thing? Is it perhaps easier to just disallow that from being possible? Allowing two classes with the same name creates a more complex situation where 90% of the time things work a certain way and then suddenly you find you have a special case. Say you have two Rectangle classes defined in separate namespaces:
class Project1.Image.Rectangle
class Project1.Window.Rectangle
It's possible to hit an issue that a source file needs to include both namespaces. Now you have to write out the full namespace everywhere in that file:
var rectangle = new Project1.Window.Rectangle();
Or mess about with some nasty using statement:
using Rectangle = Project1.Window.Rectangle;
With a single namespace in your project you are forced to come up with different, and I'd argue more descriptive, names like this:
class Project1.ImageRectangle
class Project1.WindowRectangle
And usage is the same everywhere, you don't have to deal with a special case when a file uses both types.
using statements
using Project1.General;
using Project1.Image;
using Project1.Window;
using Project1.Window.Controls;
using Project1.Shapes;
using Project1.Input;
using Project1.Data;
vs
using Project1;
The ease of not having to add namespaces all the time while writing code. It's not the time it takes really, it's the break in flow of having to do it and just filling up files with lots of using statements - for what? Is it worth it?
Changing project folder structure
If folders are mapped to namespaces then the project folder path is effectively hard-coded into each source file. This means any rename or move of a file or folder in the project requires actual file contents to change. Both the namespace declaration of files in that folder and using statements in a whole bunch of other files that reference classes in that folder. While the changes themselves are trivial with tooling, it usually results in a large commit consisting of many files whose classes haven't even changed.
With a single namespace in the project you can change project folder structure however you want without any source files themselves being modified.
Visual Studio automatically maps the namespace of a new file to the project folder it's created in
Unfortunate, but I find the hassle of correcting the namespace is less than the hassle of dealing with them. Also I've got into the habit of copy pasting an existing file rather than using Add->New.
Intellisense and Object Browser
The biggest benefit in my opinion of using multiple namespaces in large projects is having extra organization when viewing classes in any tooling that displays classes in a namespaces hierarchy. Even documentation. Obviously having just one namespace in the project results in all classes being displayed in a single list rather than broken into categories. However personally I've never been stumped or delayed because of a lack of this so I don't find it a big enough benefit to justify multiple namespaces.
Although if I were writing a large public class library then I would probably use multiple namespaces in the project so that the assembly looked neat in the tooling and documentation.
I think the standard, within .NET, is to try to do it when possible, but not to create unnecessarily deep structures just to adhere to it as a hard rule. None of my projects follow the namespace == structure rule 100% of the time, sometimes its just cleaner/better to break out from such rules.
In Java you don't have a choice. I'd call that a classic case of what works in theory vs what works in practice.
#lassevk: I agree with these rules, and have one more to add.
When I have nested classes, I still split them out, one per file. Like this:
// ----- Foo.cs
partial class Foo
{
// Foo implementation here
}
and
// ----- Foo.Bar.cs
partial class Foo
{
class Bar
{
// Foo.Bar implementation here
}
}
I'd say yes.
First, it will be easier to find the actual code files by following down the namespaces (say, when somebody e-mails you a naked exception call stack). If you let your folders go out of sync with namespaces, finding files in big codebases becomes getting tiring.
Second, VS will generate new classes you create in folders with the same namespace of its parent folder structure. If you decide to swim against this, it will be just one more plumbing job to do daily when adding new files.
Of course, this goes without saying that one should be conservative about how deep xis folder/namespace hierarchy goes.
Yes they should, only leads to confusion otherwise.
What's the standard?
There is no official standard but conventionally the folder-to-namespace mapping pattern is most widely used.
In class libraries do the folders usually match the namespace
structure or is it a mixed bag?
Yes, in most class libraries the folders match the namespace for organizational ease.