Gratuitous name-space qualifiers in C#?



  • I know, picky, picky, picky, but when I see types with name-space qualifiers in C# I presume there is some sort of name clash we are avoiding. So I'm a little miffed when I find

    using Acme.Stuff;
    snip
    public Acme.Stuff.Foo getNewFoo()
    {
        return new Acme.Stuff.Foo();
    }
    


  • Don't think it is picky at all.

    If you are going to import namespaces then use them.  If you are going to fully qualify references, then don't import namesapces.  Do one or the other, do not do both unless really necessary, as you said, to avoid name space collisions.



  • It's bad coding but it's not a WTF.



  • In our codebase, there's one really nasty instance of a class name conflict. Our assembly has a class named ClientName.Project.Model.Utility, and one of the libraries we depend on has Company.LibraryName.Utility. We don't use the latter at all, but we use other classes in the same namespace. Before I started working on it, seeing code like this was not uncommon:

    using ClientName.Project.Model;
    using Company.LibraryName;
    //...
    
    if(ClientName.Project.Model.Utility.DoSomeCalculation(inputValue) > theThreshold) {
        inputValue = ClientName.Project.Model.Utility.FigureOutNewValue(inputValue);
    }
    //...etc...
    

    Since then, we've discovered the magic of class aliases, so we can just do this:

    using MUtility = ClientName.Project.Model.Utility;
    

    And use MUtility where we had to spell it out in full before.



  • I have seen a lot of C# designer code do this.  I also have encountered annoyances on one project where multiple custom namespaces contained identially named class objects.  This occured because we had two different databases that accidently reused the same table name and we had a tool that generated our database wrapper classes, and the tool would base the class names off of the table names.  This resulted in two class objects that followed the following pattern: CorpInitials.ProgramAbr.Database.DatabaseNameA.TableName and CorpInitials.ProgramAbr.Database.DatabaseNameB.TableName.  The result in any projects that required usage of both tables even if you were using namespaces you would have to write out the name space qualifier (this happened frequently since they were related after all).



  • @pkmnfrk said:

    Since then, we've discovered the magic of class aliases, so we can just do this:

    using MUtility = ClientName.Project.Model.Utility;
    

    And use MUtility where we had to spell it out in full before.

    I fucking hate Java.



  • @morbiuswilters said:

    @pkmnfrk said:

    Since then, we've discovered the magic of class aliases, so we can just do this:

    using MUtility = ClientName.Project.Model.Utility;
    

    And use MUtility where we had to spell it out in full before.

    I fucking hate Java.
    What?


  • @Sutherlands said:

    @morbiuswilters said:

    @pkmnfrk said:

    Since then, we've discovered the magic of class aliases, so we can just do this:

    using MUtility = ClientName.Project.Model.Utility;

    And use MUtility where we had to spell it out in full before.

    I fucking hate Java.
    What?

    Java doesn't have namespace aliases so if you have two classes with the same name you have to litter the code with fully-qualified package names. This is really great when the packages are things like "com.google.foo.bar.more.and.more.and.more.and.more.shit"



  • Yeah, Visual Studio will do that if you automatically implement the stub methods from an Interface. They probably do have their own good reason for it.



  • @morbiuswilters said:

    Java doesn't have namespace aliases so if you have two classes with the same name you have to litter the code with fully-qualified package names. This is really great when the packages are things like "com.google.foo.bar.more.and.more.and.more.and.more.shit"
    Here, I made this just for you.

     




  • @DOA said:

    @morbiuswilters said:

    Java doesn't have namespace aliases so if you have two classes with the same name you have to litter the code with fully-qualified package names. This is really great when the packages are things like "com.google.foo.bar.more.and.more.and.more.and.more.shit"
    Here, I made this just for you.

     


    That's usually how women look when they see my pen--

    It's not like I like using Java.



  • @Sutherlands said:

    It's bad coding but it's not a WTF.

    Clearly, I have a worse potty-mouth than you.



  • @Nexzus said:

    Yeah, Visual Studio will do that if you automatically implement the stub methods from an Interface. They probably do have their own good reason for it.

    They will add the full namespace if you aren't using it already. You're probably thinking about explicitly implementing an interface, which prefixes each method with the interface name. It gets absurd when it does both:

    class MyClass : CompanyName.SomeLibrary.Whatever.Foo.IAwesomeInterface {
        public void CompanyName.SomeLibrary.Whatever.Foo.IAwesomeInterface.Method1(CompanyName.SomeLibrary.Whatever.Foo.ISomeOtherThing bar) {
            throw new NotImplementedException();
        }
        //etc
    }


  • @morbiuswilters said:

    Java doesn't have namespace aliases so if you have two classes with the same name you have to litter the code with fully-qualified package names. This is really great when the packages are things like "com.google.foo.bar.more.and.more.and.more.and.more.shit"

    I really hoped that Sun/Oracle had some up with some way of avoiding Class name collision (such as namespace aliasing) in later incarnations of Java.

    But, no.



  • I think that's a trivial thing to worry about. It's hard for me to imagine what bad might happen as a result of little overqualifications like that. Doing this can be an easy way to bring up the context-sensitive help in any IDE.

    What I do have a problem with is the abuse of internal namespace trees within a single shop. Namespaces are good at isolating commercial libraries from each other, but if we're sitting in adjacent offices making things with the same name, there may be some value in allowing the collision to occur.



  • @bridget99 said:

    I think that's a trivial thing to worry about...

    It's not like they cause cancer, but they are a problem. Code tells a story. What is shown should be there for a reason. The unnecessary, unneeded namespace qualifiers are an unnecessary distraction. They also add clutter, and so will tend to obscure things that do matter.

    If your deadline is in a week and you have not yet sorted out how to implement some major features, it's definitely not the time to go cleaning up the namespace qualifiers. But they should not have been put there to begin with, and if the code is not throw-away then they should not remain there forever.



  • @morbiuswilters said:

    @pkmnfrk said:

    Since then, we've discovered the magic of class aliases, so we can just do this:

    using MUtility = ClientName.Project.Model.Utility;
    

    And use MUtility where we had to spell it out in full before.

    I fucking hate Java.

    I love the subtlety in this one.



  • @rstinejr said:

    Code tells a story. What is shown should be there for a reason. The unnecessary, unneeded namespace qualifiers are an unnecessary distraction. They also add clutter, and so will tend to obscure things that do matter.

    I think I will send a suggestion on Microsoft Connect for a future release of C#. Being able to do this:

    public var getNewFoo()
    {
        return new Foo();
    }
    
    And whenever it is not clear what should be the return type, the compiler would do like Perl (without strict): guess.

    It's interesting to see that once you remove the annoyances in a compiled language, you end up with a cheap version of Perl or Python (or even javascript).



  • @morbiuswilters said:

    @Sutherlands said:
    @morbiuswilters said:
    I fucking hate Java.
    What?

    Java doesn't have namespace aliases so if you have two classes with the same name you have to litter the code with fully-qualified package names. This is really great when the packages are things like "com.google.foo.bar.more.and.more.and.more.and.more.shit"

    Ah, you mean like java.util.Date and java.sql.Date, with the added bonus that the latter derives from the former? But that you can't use it as a parameter to its constructor, so that you get beauties like these?

    import java.util.Date;

     

    public class Woof
    {
    public void meow( Date date )
    {
    statement.setDate( 1, new java.sql.Date( date.getTime() );
    }

    }

    I like Java, but whoever is responsible or JDBC should be taken out and shot.

     



  • @Severity One said:

    I like Java, but whoever is responsible or JDBC should be taken out and shot.

    I hate Java. However, we have a very special public execution planned for the JDBC folks. Right after the people who gave us Swing succumb to the pressing and let out their last breaths, we'll turn back to the main stage. There we will have the JDBC people tied to stakes. Once they are smeared in honey, we will release the fire ants..



  • @Speakerphone Dude said:

    @rstinejr said:
    Code tells a story. What is shown should be there for a reason. The unnecessary, unneeded namespace qualifiers are an unnecessary distraction. They also add clutter, and so will tend to obscure things that do matter.

    I think I will send a suggestion on Microsoft Connect for a future release of C#. Being able to do this:

    public var getNewFoo()
    {
        return new Foo();
    }
    
    And whenever it is not clear what should be the return type, the compiler would do like Perl (without strict): guess.

    It's interesting to see that once you remove the annoyances in a compiled language, you end up with a cheap version of Perl or Python (or even javascript).

    Then why not return object instead?



  • @Alex Media said:

    @Speakerphone Dude said:
    @rstinejr said:
    Code tells a story. What is shown should be there for a reason. The unnecessary, unneeded namespace qualifiers are an unnecessary distraction. They also add clutter, and so will tend to obscure things that do matter.

    I think I will send a suggestion on Microsoft Connect for a future release of C#. Being able to do this:

    public var getNewFoo()
    {
        return new Foo();
    }
    
    And whenever it is not clear what should be the return type, the compiler would do like Perl (without strict): guess.

    It's interesting to see that once you remove the annoyances in a compiled language, you end up with a cheap version of Perl or Python (or even javascript).

    Then why not return object instead?

    This reminds me of a good interview question: does the following C# code compile and how would you optimize it?

    
    try {
     if(this is Car)
       throw new Vehicle(this.Make + " " + this.Model);
    }
    catch(Object parent)
    {
      this = parent.MemberwiseClone();
    }
    
    

    (The right answer is to put down the questionnaire and try to leave the building. A red flag is to suggest to use String.Concat instead of +.)



  • 
    public void Hulk() {
        if(this is Car)
            throw new Vehicle(this.Make + " " + this.Model);
    }
    

    HTFY



  • @Speakerphone Dude said:

    try { if(this is Car) throw new Vehicle(this.Make + " " + this.Model); } \catch(Object parent) { this = parent.MemberwiseClone(); }

    (The right answer is to put down the questionnaire and try to leave the building. A red flag is to suggest to use String.Concat instead of +.)

    ;

    Well, obviously by itself it will not compile. But if it is a "snippet" from within a program it very well may... [Darn...missed the assignment to this...so I took one little liberty....]

    using System;

    namespace ConsoleApplication3
    {
        internal class Object : Exception
        {
            public new Object MemberwiseClone()
            {
                return null;
            }
        }

        internal class Vehicle : Object
        {
            public Vehicle(string s)
            {
            }
        }

        internal class Car : Exception
        {
            public string Make { getset; }
            public string Model { getset; }
            public Object @this;

            private void FUD()
            {
                try
                {
                    if (this is Car)
                        throw new Vehicle(this.Make + " " + this.Model);
                }
                catch (Object parent)
                {
                    @this = parent.MemberwiseClone();
                }
            }

        }
    }



  • using System = Initrode;
    using Initrode = System;

    public static void Main(string[] args)
    {
    System.Object businessObject = new System.Object();
    Initrode.Console.WriteLine(businessObject.ToString());
    }

    GRATUITOUS NAMESPACE BATTLES!!!

Log in to reply