5

I have a problem how to go about naming my namespaces and classes. I already figured they shouldn't both have the same name, as it causes all kinds of problems. Most notable problem for me is that I need to fully qualify the class or make an alias. Here is what I have:

Model.DataSource.DataSource
Model.DataSource.FileSystemDataSource
Model.DataSource.JsonDataSource
Model.DataSource.XmlDataSource
Model.DataSource.DataSourceConstraints
Model.DataSource.DataSourceStorage
Model.DataSource.DataTable
... // more others

Model.QueryStorage.QueryStorage
Model.QueryStorage.FileSystemQueryStorage
... // more others

Model.Project.Project
Model.Project.ProjectFactory

As you can see, I have 3 classes that are named same as packages they are in. Two of them are interfaces so I could consider prefixing them with I but I really don't like this convention. I also heared the proposition to name package like ProjectUtils or something. But I think these are not utils, they are legit domain objects. I could alias, with using but what is a better name for Project than Project?

I can't figure out a way to have sensible names for my classes without duplicates.

Improve this question
6
  • 2
    You don't like prefixing interfaces? So you are completely fine with not knowing whether MyClass : Foo, Bar actually compiles, since Foo and Bar could both be classes, or interfaces? Even if you don't care for it, remember to write code as if the next guy maintaining it is a maniac with an axe, who knows where you live...
    – oerkelens
    Jun 12, 2016 at 11:13
  • I will know almost instantly if it compiles as I have an IDE that would underline that. In java you can say Foo extends Bar implements Baz where Bar can be interface or class, and same for Baz and noone needs an I. You usually know why and what you want to implement/inherit from and why you are doing it.
    – Łukasz
    Jun 12, 2016 at 11:18
  • 3
    So because you don't need it in Java, you won't use it in C#. Let's say I hope I never get to maintain your code; actually, I pity anyone who would. Not following industry standards messes up other people's expectations and makes your code unnecessarily hard to maintain. Not a good way to go.
    – oerkelens
    Jun 12, 2016 at 11:22
  • My logic is not it is fine in java so I will just do this in totally different language in the same way. My thinking is that both languages are no different, despite having a different syntax you still don't know if something compiles or not unless you check other files or try to compile it. I think you got the point with the convention and expectations though, but I think as long as a project chooses a convention and uses it consistently I woudln't say it's a bad thing.
    – Łukasz
    Jun 12, 2016 at 11:27
  • 1
    Just to add my voice to what others have said. Your personal preference over whether to prefix interfaces with an I or not is not important. The primary audience of your code is other developers and so you have a duty to make your code easy to read. That means following the conventions of the language. So when writing Java, don't use the I; when writing C#, you should use it.
    – David Arno
    Jun 12, 2016 at 18:12

3 Answers 3

Reset to default
10

You're right that you shouldn't name the namespace the same as a type it contains. I think there are several approaches you can use:

  • Pluralize: Model.DataSources.DataSource

    This works especially well if the primary purpose of the namespace is to contain types that inherit from the same base type or implement the same interface.

  • Shorten: Model.QueryStorage

    If a namespace contains only a small number of types, maybe you don't need that namespace at all.

  • Make enterprisey: Model.ProjectSystem.Project

    This can work especially for features that are important part of your product, so they deserve their own name.

Two of them are interfaces so I could consider prefixing them with I but I really don't like this convention.

You really should, if your code is used by others (i.e. it's a library) or if you don't want to confuse newcomers to your code.

Improve this answer
4

.NET design guidelines requires I prefix for interfaces. It recommends singular form for classes (Collection suffix for everything implementing IEnumerable) and plural form for namespaces.

Improve this answer
4
  • That could solve some problems. DataSource could be DataSources, but QueryStorage contains just one QueryStorage and it is unlikely it will contain more. I am really against the hungarian notation, and even if I wasn't, Project is a concrete, kinda value, class that will never have more than one implementation, so how I go about naming that? Project package contains only one Project.
    – Łukasz
    Jun 12, 2016 at 10:28
  • 1
    @Lukasz Preceding an interface with an I is not hungarian notation at all. Regarding Project you can change that so easy later on I would not overanalyze it. But still if you only have one class in the namespace you should consider if it warrants a namespace at all.
    – Amenti
    Jun 12, 2016 at 10:43
  • I have 2 classes there currently, maybe more to come. I know things are easy to change, I am moving on with my project anyway but in the meantime I figured it would be nice to find out how would I solve this eventually. About the hungarian notation, you are right, point taken, but in principle it is the same to me. It is known that bFlag is a bool and it can be simply flag as well as IDataSource is known to be an interface even without the prefix.
    – Łukasz
    Jun 12, 2016 at 11:04
  • 3
    It's not the same. Other coders expect you to precede interfaces with an I and they expect you to not use hungarian notation with variables which is frowned upon usually. This is about industry standards. If you want your code to be easily readable and understandable by other coders you should follow the established patterns imho.
    – Amenti
    Jun 12, 2016 at 12:31
0

You need to prefix namespace names with a company name to prevent namespaces from different companies from having the same name.

examples:

Fabrikam.Math
Litware.Security

eventually your namespace must have this structure:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
Improve this answer
2
  • 1
    Yes, they are prefixed. I skipped that part to show only what is relevant. But this doesn't solve my problem at all.
    – Łukasz
    Jun 12, 2016 at 9:41
  • Don't downvote an answer just because it didn't help the OP
    – fjch1997
    Oct 10, 2019 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.