Should I agree to ban the "using" directive from my C# projects?

Question

My colleague insists on explicitly specifying the namespace in code as opposed to using the using directive. In other words he wants to use the fully qualified name for each type every time this type occurs in code. Something like

public class MyClass
{
    public static void Main()
    {
        System.Console.WriteLine("Foo");
    }
}

instead of:

using System;
public class MyClass
{
    public static void Main()
    {
        Console.WriteLine("Foo");
    }
}

You can imagine the consequences.

The pros he gives:

1. It's simpler to copy and paste code into other source files.
2. It is more readable (you see the namespaces right away).

My cons:

1. I have to write more
2. The code is less readable (I guess de gustibus non disputandum est)
3. No one does it!

What do you think about this?

Answer 1

If you need to copy and paste code around so much as to actually benefit of having fully qualified types, you've got bigger problems.

Also, do you plan on remembering which namespace every single class is in in order to be able to type it fully qualified?

Answer 2

The Law of Demeter says you should use only one dot:

For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as "use only one dot". That is, the code "a.b.Method()" breaks the law where "a.Method()" does not.

Of course, this is not always practical. But long strings of dot-separated identifiers violate accepted practice.

EDIT: This answer seems controversial. I brought the Law of Demeter up mostly as a style guide, and most replies here seem to agree that limiting the number of dots is a good idea. In my opinion, jQuery (and JavaScript) suffer from readability problems, partly because excessive dots creep into any non trivial program .

Answer 3

Because we have a tool in C# for auto-setting the using statement, by pressing Ctrl+dot - I can't see any reason not to use it. The other "cool" thing here, is:

Think about you have a two namespaces:

ConsoleNamespace1

and

ConsoleNamespace2

Both have a Console class. Now you can change all the references to ConsoleNamespace2, with just a single line of code - that's cool.

My advice: Use using if you can, the full if you must. I don't think the fully one, if easier to read. Know your framework, and this will never be a problem.

Answer 4

Oh boy. One step might be teaching your collegue about ctrl+. It will automatically insert using statements for you.

Answer 5

My general rule is that if I am going to use items from a particular namespace more than a few times, it gets a using directive. However I don't want to clutter up the top of the file with using directives for things that I only use once or twice.

Answer 6

Making it easier to move code around by copy and paste is simply a non sequitur, and quite possibly a warning sign of potentially dangerous practice. The structure and legibility of code shouldn't be dictated by ease of edit.

If anything it makes the code less readable and more specific - personally I'm not interested where standard objects live, it's akin to addressing your colleague by their complete given name, prefixed with the street address of your workplace.

There are times, however, where occasionally it makes the code more readable, so hard and fast rules are not applicable, just common sense.

Answer 7

I recommend against the proposition of your colleague. For me reading code is much easier if you don't have a long namespace cluttering the line. Just imagine this:

Namespace1.Namespace2.Namespace3.Type var = new Namespace1.Namespace2.Namespace3.Type(par1, par2, par3);

as opposed to:

Type var = new Type(par1, par2, par3);

Regarding copy-paste - you do have Shift+Alt+F10 that will add the namespace, so it shouldn't be a problem.

Answer 8

What do I think about this?

I think that a person who would come up with an idea like this, and who would justify it the way he has, is very likely to have a number of other fundamental misunderstandings about the C# language and .NET development.

Answer 9

It's also worth noting that a tool like ReSharper (why aren't you already using it?) will add the appropriate 'using' lines for you pretty much automatically.

Answer 10

For a slightly different answer: LINQ.

Extension methods are obtained only via "using" statements. So either the query syntax or the fluent interface will only work with the right "using" statements.

Even without LINQ, I'd say use "using"... reasoning that the more you can understand in fewer characters, the better. Some namespaces are very deep, but add no value to your code.

There are other extension methods too (not just LINQ) that would suffer the same; sure, you can use the static class, but the fluent interface is more expressive.

Answer 11

Install ReSharper on you machines. Sit back and let it guide your colleague to righteousness. Seriously, there are bigger battles but this is the kind of coder to avoid if it takes more than two minutes to try to educate.

Answer 12

One of the reasons you use "using" is that it tells anyone reading the source the sort of things your class will be doing. Using System.IO tells a reader you're doing I/O operations, for example.

Answer 13

You can also use aliases...:

using diagAlias = System.Diagnostics;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            diagAlias.Debug.Write("");
        }
    }
}

Answer 14

The biggest problem I find with not using the "using" directive isn't on instantiantion and definition of classes. It's on passing in values to functions that are defined defined in the namespace. Compare these two pieces of code (VB.Net, because that's what I know, but you get the picture).

Module Module1

    Sub Main()
        Dim Rgx As New System.Text.RegularExpressions.Regex("Pattern", _
            System.Text.RegularExpressions.RegexOptions.IgnoreCase _
            Or System.Text.RegularExpressions.RegexOptions.Singleline _
            Or System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace)


        For Each result As System.Text.RegularExpressions.Match In Rgx.Matches("Find pattern here.")
            'Do Something
        Next
    End Sub

End Module

And this

Imports System.Text.RegularExpressions

Module Module1

    Sub Main()
        Dim Rgx As New Regex("Pattern", _
            RegexOptions.IgnoreCase _
            Or RegexOptions.Singleline _
            Or RegexOptions.IgnorePatternWhitespace)


        For Each result As Match In Rgx.Matches("Find pattern here.")
            'Do Something
        Next
    End Sub

End Module

In cases like this where lots of enums are used, as well as declaring your variables inline in a for loop, to reduce scope, not using "using" or "imports" in the case of vb.Net, can lead to really bad readability.

Answer 15

You really want to maintain code that way? Even with intellisense all that typing is not going to be productive.

Answer 16

Instead of 'copy-n-paste' I call it 'copy-n-rape' because the code is abused 99.9% of the times when it is put through this process. So there, that's my answer to your colleague's #1 justification for that approach.

On a side note, tools like Resharper will add the using statements at the top when you add code that needs them to your code (so even if you 'copy-n-rape' code like that you can do so easily).

Personal preferences aside, I think your justifications are much more valuable than his, so even assuming they are all valid points, I'd still reccomend writing the using statements at the top. I would not make it a 'ban' though, since I see coding standard as guidelines rather than rules. Depending on your team size it might be very hard to enforce things like that (or how many spaces for indentation, or indentation styles, etc etc).

Make it a guideline so that all the other developers feel free to replcae the fully qualified names with the shorter versions and, over time, the code base will fall in line with the guideline. Keep an eye out for people taking time away from doing work to simply change all the occurrences of one style to the other - 'cause that's not very productive if you're not doing anything else.

Answer 17

The minute your colleague said "copy-and-paste code", he lost all credibility.

Answer 18

I think with the IntelliSense features in Visual Studio and using some third-party products like ReSharper, we no longer care about either to make our code fully qualified or not. It became no longer time consuming to resolve the namespaces when you copy and paste your code.

Answer 19

He might have a point with somethings. For instance, at a company I work at we have a lot of code generated classes and so all of our code generated classes we use the fully qualified names for classes in order to avoid any potential conflicts.

With all the standard .NET classes that we have, we just use the using statements.

Answer 20

In a system like .NET, where there are types in namespaces, you have to make a decision: is a namespace part of the name, or is it an organizational tool for types?

Some systems choose the first option. Then, your using directives would be able shortening the names that you use the most often.

In .NET, it's the latter. For example, consider System.Xml.Serialization.XmlSerializationReader. Observe the duplication between the namespace and the type. That's because in this model, type names must be unique, even across namespaces.

If I remember correctly, you can find this described by the CLR team here: http://blogs.msdn.com/kcwalina/archive/2007/06/01/FDGLecture.aspx

Its simpler to copy and paste code into other source files.

True, but if you're copy/pasting a lot of code, you're probably doing it wrong.

It is more readable (you see the namespaces right away)

Seeing the namespaces isn't important, since, at least when you're following Microsoft's guidelines, type names are unique already; the namespace doesn't really provide you with useful information.

Answer 21

I'm someone who has a tendancy to fully qualify namespaces. I do it when I'm using components which i'm not familiar with/ haven't used for a long time. I helps me remember what's in that namespace so next time I'm looking for it/ related classes.

It also helps me twig to whether I have the appropriate references in the project already. Like if I write out System.Web.UI but can't find Extensions then I know I forgot/ who ever set up the project forgot to put in the ASP.NET AJAX references.

I'm doing it less and less though these days as I'm using the shortcut to qualify a class (Ctrl + .). If you type out the name of the class (correctly cased) and press that shortcut you can easily fully quality/ add a using statement.

It's great for the StringBuilder, I never seem to have System.Text, so I just type StringBuilder -> Ctrl + . and there we go, I've added the using.

Answer 22

"The minute your colleague said "copy-and-paste code", he lost all credibility." ditto.

"The Law of Demeter says..." ditto

...and I add. That's just absurd, not using using statements. Get ReSharper, find some way to teach this fellow how it's done, and if it doesn't seem to take effect - with the reasons given, it's time to start looking into a different job. Just the correlations of what goes along with such notions as not using using statements is scary. You'll be stuck working 16 hr days fixing mess if that's one of the rules. There is no telling what other type of affront to common sense and logic you'll face next.

Seriously though, this shouldn't even be brought up with tools like ReSharper available. Money is being wasted, buy ReSharper, do code cleanup, and get back to making usable software. :) That's my 2 cents.

Answer 23

if you are repeatedly copying and pasting code, doesn't that point to creating a standard DLL to include into each of your projects?

I've worked on projects using both methods before and have to say having the "Using" statements makes sense to me, it cuts down on the code, makes it more readable and your compiler will ultimately optimise the code in the right way. The only time you may have an issue is if you have two classes from two namespaces which have the same name, then you would have to use the fully qualified name...but thats the exception rather than the rule.

Answer 24

Isn't the fact that Visual Studio includes lots of using statements at the top of pretty much every file it creates a hint that using statements are considered good practice?