CODEWITHSUNDEEP
c#.netcoding-style
ghostJago
ghostJago

Reputation: 3434

convention - .net namespaces in projects with physical folders

Suppose I have a .NET project named GhostJago.WebScraper

In this project I have a file containing a class, WebScrapeEngine. The class is contained in the namespace GhostJago.WebScraper {...}.

Now I add a new folder and put a class file in that folder. My structure is basically:

GhostJago.WebScraper (Project)
 |-> AddIns (folder)
    |-> WebScraperAddIn.cs (c# file)
 |-> WebScraperEngine.cs (c# file)

Question: Should the namespace in WebScraperAddIn.cs be namespace GhostJago.WebScraper.AddIns {...} or does it not matter?

Upvotes: 3

Views: 1101

Answers (5)

Jon Rea
Jon Rea

Reputation: 9455

It is best practice to ensure that your namespace structure matches your physical file/folder structure.

EDIT:

Should the folders in a solution match the namespace?

convention - .net namespaces in projects with physical folders

Upvotes: -1

dash
dash

Reputation: 91472

It's definitely a good thing to do, let me give you an opposing example of how not using it can be bad

I worked on a system a couple of years ago that dealt with a wide range of products. All of these were in the folder Company.System.Products. In fact, many of the classes in this folder also had multiple classes in one cs file.

By the time there were 150 products, the following was a regular occurence:

  1. It became difficult to find anything
  2. It became difficult (in terms of merging on checkin) for people to work on products of a similar type (although this is not a namespace issue, it is an organizational issue)
  3. People became confused; where do I add something new?
  4. People new to the project had no idea of where to start

Now, obviously, from an editor point of view, having lots of objects in one namespace is a bad thing as context menu's are full of items, making it difficult to look at the one you want. So adding namespaces is a good start. However, then, moving the namespaces into physical folders made it much easier to navigate the namespaces, especially outside of the IDE. And moving the classes into individual files meant smaller classes with hardly any merge conflicts. It also makes it much easier to start pushing out folders into separate assemblies.

So having a degree of organization in your project can just make things easier!

Upvotes: 4

Tony Hopkinson
Tony Hopkinson

Reputation: 20320

The only reason to do so is if you stick to the convention, it's easy to remember, and new people will pick things up quick. .Net simply doesn't care, but to me the question is why can't we keep it simple.

Nothing worse than a legacy code base, where as well as not having any other clue, you aren't even sure where the code is....

Upvotes: 1

Coding Flow
Coding Flow

Reputation: 21881

I would agree with Jon that on the whole it is best practice to ensure that your namespace structure matches your physical file/folder structure, because it makes finding stuff easier, you know the namespce of a class then you know what file and folder it is in. OK you have go to definition but it is easy to get lost following a chain of go to definitions. However if you have a good reason not to do it, like you want all your domain related classes in the same folder (e.g. all your customer classes, order classes etc.) but all you DAL classes in the same namespace then it is fine. Mainly with these things the best rule over all is pick a convention and stick to it.

Upvotes: 1

Adam Robinson
Adam Robinson

Reputation: 185593

Mapping namespaces to folder names is purely convention. Its purpose is to make finding source code easier in larger projects.

That being said, there is no particular benefit or need from a technical perspective to do this. In other words, it doesn't matter.

Upvotes: 1

Related Questions