Namespace Naming Conventions

namespace naming conventions

From the Namespace Naming Guidelines:

The general rule for naming namespaces
is to use the company name followed by
the technology name and optionally the
feature and design as follows. Copy
Code

CompanyName.TechnologyName[.Feature][.Design]

Generally it's a really bad practice to start including things into the default namespace of a framework or library. This can cause confusion in terms of whether a new namespace is part of the existing library that is part of a framework that is distributed to everyone, or is part of a custom framework that was added by someone else.

Also, the naming convention tries to avoid namespace collisions by having unique identifiers such as CompanyName. It also reduces any confusion and issues in terms of the source of the new library.

This is not only a Microsoft thing, but in the Java as well. Namespaces in Java, called "packages" has the following convention:

The prefix of a unique package name is
always written in all-lowercase ASCII
letters and should be one of the
top-level domain names, currently com,
edu, gov, mil, net, org, or one of the
English two-letter codes identifying
countries as specified in ISO Standard
3166, 1981.

Subsequent components of the package
name vary according to an
organization's own internal naming
conventions. Such conventions might
specify that certain directory name
components be division, department,
project, machine, or login names.

So, if I had a super awesome piece of software, it may be in the net.coobird.superawesomesoftware package.

And using package names that contain the default java., javax., com.sun. packages are a big no-no.

In C#, what are the namespace naming conventions for individuals?

IMHO,If you release it as individual I think better name it like your project/program name, let's imagine that you writing a library with code name "SuperLib" : SuperLib.SuperFeature.SuperDesign.

C# Namespace naming conventions for extensions of existing libs

There are a few articles on namespace guidance and best practices. Best practices are opinions and do change over time.

Let's start with the bit about you having open-source in your project that you see will eventually be extended.

1. If at all possible, don't extend it. It's open source and that allows you to do a couple things before considering extending. First, if the feature you are writing for the open source makes sense, you could contribute to it. Second, you could fork the repository and maintain your own copy with the feature you added.

2. If you must extend it, it should be packaged and distributed as a NuGet package. Here's some guidance on open-source libraries in general. One thing I didn't see in there was consider using the same license for your code as the code you're extending. And here is some more detail on the namespace guidance if you go this route.

Noteworthy for this case:

✔️ DO prefix namespace names with a company name to prevent namespaces from different companies from having the same name.

❌ DO NOT give the same name to types in namespaces within a single application model.

The one bit you left out is whether you are extending with instance types, like a class or implementation of an interface or with extension methods. It makes a bit of a difference.

This article from Microsoft Docs has some guidance that is geared towards extension methods

❌ DO NOT put extension methods in the same namespace as the extended type unless it is for adding methods to interfaces or for dependency management.

✔️ CONSIDER defining extension methods in the same namespace as the extended type if the type is an interface and if the extension methods are meant to be used in most or all cases.

c# namespace naming conventions

Interesting question. I've never seen any advice beyond "use plurals where appropriate" for C#.

Let's assume that the namespace is MyCompany.Repositories

Borrowing from a similar question posed in the Java world I would suggest that plural is valid. The components that live within the Repositories namespace will be homogeneous in the sense that they are all repositories (UserRepository, StudentRepository, LocationRepository, etc).

Conversely, a namespace like MyCompany.ReportingEngine would be valid as a singularly-named namespace, as this namespace may contain heterogeneous classes that do very different things (IE a query generator class, a report model, a field model, a filtering model). MyCompany.ReportingEngines would suggest that this namespace contains different types of classes that are reporting engines.

Namespace naming convention when [CompanyName] starts with a lower case i

it seems like you're using iWare, or your company name, as your root namespace.

On my projects, I generally specify my root namespace in/using the property window of MyProject, or MenuItem 'Project' > 'Properties' > 'Application' - 'root namespace' textbox on right.

Thus, I don't specify it in my coding at all, unless I'm referencing it from another component/project as an import.

Naming classes and namespaces the same?

You should follow .NET conventions and name your interface INode. Then classes inside the Node namespace will implement your INode interface.

namespace vs naming convention

I think a good rule is: Use namespaces to identify a library (The contents of a library). Use nested namespaces in very specific cases (Cases where the contents of that nested namespace could be considered a library itself).

An example of that could be the standard library: It provides its functionality through the std namespace, and (for example) provides the chrono library (it could be viewed as a library itself) through the std::chrono namespace. Other example could be Boost and its libraries.

Good Namespace Naming Conventions

It seems Ok to me anyway. I would stay away from abbreviations though, that would get confusing and force people to have to know the abbreviations or look them up. Also they become unreadable and unspeakable.

"Lets take a look at the BusObjConfIntContYYYYmmdd package now..."

One issue you might run into is names with subtle differences. With length of names being a possible issue, your eyes might gloss over the whole thing and pick up only part of it. Would there ever be a case where this happened?:

BusinessObjects.Incidents.Classifications
BusinessObjects.Classifications.Incidents

or

BusinessObjects.Forms.ProjectManager.Exportable.Windows.XP
BusinessObjects.Forms.ProductManager.Exportable.Windows.XP

That contrived example might become a problem.

---

Related Topics