none
Extension namespace naming convention RRS feed

  • Question

  • In a solution with several projects, some with several namespaces of varied hierarchy depths, I typically create a namespace parallel to those which may utilize it, or directly beneath a single namespace when only it exports types that could use the extensions. In cases like this, what convention do others follow for naming the namespace and the classes themselves? Static analysis complains when namespaces or types match even across hierarchical boundaries. Further, since the extension classes themselves are never used directly (except possibly in tests) I don't know if it matters if the type names potentially collide?

    How do others layout this aspect in larger solutions?
    Saturday, November 18, 2017 5:10 PM

Answers

  • Expanding on Fei's answer, I think there are 2 different types of extension classes (general and specialized) you may have and each uses a different namespace approach. Let's take a generic class like HttpClient as an example. A general extension add new functionality that is generally reusable on a class. For HttpClient it might be a generic method to handle errors in the response. A specialized extension is for specialized use cases that not every app needs. For HttpClient that might be specialized calls for working with REST APIs.

    For general extensions, that is what Fei was talking about. In my own code all the namespaces follow the <Company>.<Product> convention so that is where it starts. The remainder of the namespace follows the namespace convention that exists in the core library, for consistency. So general HttpClient extensions would go in the MyCompany.MyProduct.Net.Http namespace. 

    For the class name itself I follow the convention of core where it is type-Extensions (i.e. HttpClientExtensions). But sometimes, when it makes sense, I might also use the base name if it doesn't conflict with another type (ie. Enumerable for IEnumerable).

    For specialized extensions I use a child namespace just like I would if I weren't implementing extensions. So for the above example I'd use MyCompany.MyProduct.Net.Http.Rest.

    For the class name I would tend to follow a similar convention to general extensions but because code may mix namespaces (not generally an issue though) I include the specialization. Continuing the above example I'd use something like RestHttpClientExtensions or something.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Ritmo2k Monday, November 20, 2017 3:45 PM
    Monday, November 20, 2017 2:58 PM
    Moderator

All replies

  • Hello Ritmo2K,

    >> what convention do others follow for naming the namespace and the classes themselves

    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.

    CompanyName.TechnologyName[.Feature][.Design]

    You could get more detailed information from here.

    https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces

    >>since the extension classes themselves are never used directly (except possibly in tests) .I don't know if it matters if the type names potentially collide?

    It couldn't bring type names potentially collide. When you define a extend class under different namespace. The type full name is including your current namespace and extend class name. Even though you define a class type has the same class name under other namespaces. The compiler will also recognize it as different type. The following image indicates that when you invoke the extend method actually the compiler invoke the ExtendMethod by static " ExtendClass" name .

    This is my testing code.

    namespace ConsoleApp1
    {
        class Program
        {
            static void Main(string[] args)
            {
                people p = new people();
    
                p.extendMethod();
    
            }
        }
    
        class people
        {
            public string Name;
    
            public void SetName()
            {
    
            }
        }
    }


    namespace namespace1
    {
       static class ExtendClass
        {
            public static string extendMethod(this people p) {
                return "Test123";
            }
        }
    }

    Sincerely,

    Fei Hu


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, November 20, 2017 7:57 AM
    Moderator
  • Hello,
    >> CompanyName.TechnologyName[.Feature][.Design]

    So if you have 10 features where each feature has 10 designs and most have extensions that you want in discrete namespaces so they can be enabled with using declarations only when desired, what do you name the namespace? Do you use "Extensions" for all of them?

    Monday, November 20, 2017 2:12 PM
  • Expanding on Fei's answer, I think there are 2 different types of extension classes (general and specialized) you may have and each uses a different namespace approach. Let's take a generic class like HttpClient as an example. A general extension add new functionality that is generally reusable on a class. For HttpClient it might be a generic method to handle errors in the response. A specialized extension is for specialized use cases that not every app needs. For HttpClient that might be specialized calls for working with REST APIs.

    For general extensions, that is what Fei was talking about. In my own code all the namespaces follow the <Company>.<Product> convention so that is where it starts. The remainder of the namespace follows the namespace convention that exists in the core library, for consistency. So general HttpClient extensions would go in the MyCompany.MyProduct.Net.Http namespace. 

    For the class name itself I follow the convention of core where it is type-Extensions (i.e. HttpClientExtensions). But sometimes, when it makes sense, I might also use the base name if it doesn't conflict with another type (ie. Enumerable for IEnumerable).

    For specialized extensions I use a child namespace just like I would if I weren't implementing extensions. So for the above example I'd use MyCompany.MyProduct.Net.Http.Rest.

    For the class name I would tend to follow a similar convention to general extensions but because code may mix namespaces (not generally an issue though) I include the specialization. Continuing the above example I'd use something like RestHttpClientExtensions or something.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Ritmo2k Monday, November 20, 2017 3:45 PM
    Monday, November 20, 2017 2:58 PM
    Moderator