Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Another developer at my company created a new class library using the following namespace:
MyCompany.Repositories.Users
Based on my experience over the years I would expect this namespace to be named as:
MyCompany.Repository.User
Which style do you normally use for your namespaces? I was thinking my style was somewhat standard. It looks cleaner to me. Can you provide any authoritative urls which recommend 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.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been working on a project in Unity, and was trying to figure out how to abbreviate a large number into a more readable format. I found somebody who asked the same question and got some code, but the person who gave that code had 2 classes in the same C# script. I am new to Unity and C# in general, so this was not something I had seen before.
What I would like to know is when to put classes in different scripts, when to put multiple classes in the same script, and if I do put multiple classes in the same script how that affects that script and other scripts in the project.
From a C# logical point of view, it does not matter where a class is. From the practical perspective, it is usual to put every type (class, struct) in its own code file. I often make an exception for enums and put enums belonging to the same realm into the same file, e.g. things like DisplayStyle, SortOrder, Visibilty could be in a file named AppearanceEnums.cs. Enums are mostly small and don't contain logic.
for Unity, see: How to architect code as your project scales
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We have the current structure:
BusinessName.Common - common entities, classes, utilities
BusinessName.Services - business services
We're adding a sub-unit called "Medical", of which it will contain a similar structure. I'm stuck deciding on the best naming convention.
Option 1
BusinessName.Medical.Common
BusinessName.Medical.Services
Option 2:
BusinessName.Common.Medical
BusinessName.Services.Medical
There will eventually be more sub-units such as this.
I would stick with Option 1, because each domain should mimic the same child namespace naming scheme.
If you call BusinessName.Common a shared library across all domains (what you call units...), a specific domain common members are of the whole domain, thus, your naming scheme should be BusinessName.[DomainName].Common, BusinessName.[DomainName].Services.
Anyway, let me add more value to this answer. You said that Common project/namespace would contain common entities, classes, utilities. I'm not agree with this. A common library should be a cross-layer library (vertical). My advise is that you should organize your solution this way:
BusinessName.Common: Infrastructure code. Any domain-related code shouldn't be here. Classes, interfaces and enumerations here should be usable from any layer and tier.
BusinessName.Domain: Common domain entities and services. I would put here common domain interfaces, abstract classes, base classes...
BusinessName.Domain.[SomeDomain]. For example BusinessName.Domain.Medical. I would put here everything about domain. In a specific domain there're no common entities to any other domain, because this would defeat the purpose of organizing your project in domains.
In my own projects I prefer to use Shared identifier instead of Common, but this is just my opinion.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
i am now developing a c# solution with 5 projects.
When i created the project under the solution, each project has its own namespace. My question is should i unify the namespaces using the solution namespace to avoid any scope problems later ?
Besides, i have a project for the Win Forms and using folders under it (to organize the forms). Each folder has several form.
When i want to use the form, i found that i have to mention the folder also.
What should i do then ?
Namespace is not related to the project structure but it is good habit follow the project structure. This make orientation in code much better. There is no need to unify namespace from scope reason. It should mirror your logical project layout. eg. your namespace can start with company (or product) name and than follow with component and then follow with your structure:
MyProduct.DataLayer
MyProduct.UI
MyProduct.Tools
MyProduct
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Let's say I own a domain called www.john-doe.com. How would I write an appropriate namespace in C#?
Is it Com.John_Doe.<product-name> ?
All I read about C# namespace convetions is that it should use PascalCase. But what about the minus sign? Is it appropriate to write an underscore for it?
According to .NET namespace conventions, you should use pascal casing in namespaces (unless that goes against non-standard casing your company/brand/product uses). And according to capitalization conventions, pascal casing should not include underscores. General naming conventions also tell you to not use hyphen (which will actually produce compiler errors in C# anyway).
Unless Com is intended to be replaced with your company name (from the context, "John Doe" sounds like the company) You should just go with:
JohnDoe.<ProductName>
I think it is personal preference. E.g. my preference is JohnDoe.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
due to unit-testing we create for every class an Interface. The .Net Framework coding standards say that every class, interface, enum, etc. should be located in a different file.
As these interfaces are so closely related with the class we were thinking of creating an internal coding-standards rule to put together the class and the interface.
Have you seen this approach before? What do you think about it?
PD: Always talking about interfaces used only to mock the classes, not 'real' interfaces that can have more than one implementation.
You should follow .NET coding standards and separate the interfaces into their own files. You could create a folder Interfaces within your project. I usually have Concrete, Abstract and Interfaces folders within my projects.
Developers who may be unfamiliar with your solution will have a hard time finding interfaces if they are in class files.