When you look at the code for the Winforms Designer, you see things like this:

this.label1.Font = new System.Drawing.Font("Microsoft Sans Serif", ... etc.

instead of

using System.Drawing;
label1.Font = new Font("Microsoft Sans Serif", ... etc.

The same is true of tools like Linq to XSD, XSD2Code and, I suspect, of Linq to SQL. These tools generate hoards of code with extremely long fully-qualified names.

Wouldn't it be easier to generate the appropriate using statements, and ditch the long names? Or is there some technical reason for this that I'm missing?

Note: For those folks that are baffled by the notion that I might want these classes to actually be readable by a human, note that this is exactly my goal. I have an XSD with about 300 classes in it, I don't want to write them all by hand, and yes, I'd like them to look like ordinary code written by humans.

  • 2
    Amen! None of the generated code follows their own recommendations (StyleCop) either. Commented Feb 13, 2013 at 0:09
  • The using directive is designed to make the code more readable for a human. Compiler generated code is not designed to be read by humans, so why add the extra complexity of trying to make it human readable?
    – MattDavey
    Commented Feb 13, 2013 at 9:18
  • If it's pretty much specific namespaces it wouldn't be extraordinarily difficult to write something that adds the using statements and shortens the long names in a later pass. You could always submit your code to the project.
    – psr
    Commented Feb 13, 2013 at 21:24

4 Answers 4


Code generators explicitly declare the classes they are using to prevent unexpected behaviour from naming conflicts.

If a project includes a class with the same name as a class in another namespace, it introduces ambiguity. Where there's ambiguity, the compiler defaults to the local namespace. Consider this:

using System.Drawing;

namespace MyProject {
    class MyClass {
        void InitialiseComponent() {
            this.label1.Font = new Font("Microsoft Sans Serif", ...);

This works fine as it is. But what if we add a new Font class to the project?

namespace MyProject {
    class Font : System.Drawing.Font {
        public Font(string fontName, ...) { ... }

Now we have System.Drawing.Font and MyProject.Font. The code in MyProject.MyClass.InitialiseComponent() still compiles and runs. But which version of Font does it use?

The compiler defaults to the local namespace of MyProject.MyClass and uses MyProject.Font, even though using System.Drawing is defined.

Is this what the programmer wanted? It's not the IDE's job to guess that. The programmer should explicitly state whether they want to use their implementation of Font or System.Drawing.Font.

Within a single project, the IDE could detect this change and alter all code generated files to clarify which Font to use. But what if the project isn't currently loaded? How can the IDE know which files require future maintenance? Start by being specific and there's never ambiguity.

  • I see that you're getting a lot of upvotes with this, but the likelihood of me creating my own font class is pretty close to zero. :) Commented Feb 13, 2013 at 15:31
  • 2
    @RobertHarvey yes, but why take the risk? The principal is sound, fully qualified names eliminate the (future) possibility of a clash.
    – sdg
    Commented Feb 13, 2013 at 16:12
  • 1
    Also, why would a programmer bother coding a case for Font saying "A user probably wont define their own Font class, so let's not qualify it." Suppose that were reasonable (personally I don't think so, but whatever). Now what about this other class List? Now what about this other class Input? Now what about this other class Foo? Each one of these would be a special case. It's not my job to decide other programmer's creativity levels. Commented Feb 13, 2013 at 19:26
  • What if I'm from Andorra and want to create a class named Source, which in the local language, Catalan, is Font? :-P Commented Feb 13, 2013 at 22:11

Code generators are usually designed to create machine readable code more than human readable code. Humans are expected to mostly work with the original format used as input to the generator. using statements enhance human readability, but computers don't care.

Try going through the exercise of writing a simple code generator as you describe, and you'll see why they use the fully-qualified names. Usually you make some sort of abstract syntax tree based on the original input format, then you walk the tree to generate the code. Using using statements would require keeping an extra "registry" of using statements you want to use, checking it for duplicates, then going back to insert them at the top of the file. That's worth it if it's required, like say an include statement, but it's a lot more trouble than it's worth for something with an easy enough workaround.

  • 1
    That's great if you can treat the generated code as a black box, and never have to look at it or modify it. That's not always the case, though. Commented Feb 13, 2013 at 0:16
  • It seems to me that a keeping track of inserted using statements would actually be pretty straightforward. Commented Feb 13, 2013 at 0:33
  • @Winston Ewert: it's still additional code to write and maintain. Possibly developers of code generators decided that it's not worth it. Commented Feb 13, 2013 at 0:34
  • 3
    @RobertHarvey You really shouldn't be modifying generated code though, that leads to all sorts of problems. Ideally you would modify the generator itself.
    – Tacroy
    Commented Feb 13, 2013 at 0:43
  • 2
    @RobertHarvey Ick, that's pretty gross. I think the the thing to do then would be to either get off of the bad tool (which probably isn't an option), or figure out a way to do your Find and Replace stuff automatically. Any workflow that involves a human looking at generated code is flawed.
    – Tacroy
    Commented Feb 13, 2013 at 0:55

If you created or imported another library that also defined Font, then without full qualification the generated code would have an error.

  • 1
    But wouldn't that also be true of ordinary, non-generated code that you write yourself? Commented Feb 13, 2013 at 0:03
  • @Guy Coder: Not really. If there are appropriate usings at the top of the generated file, it should not cause errors. Commented Feb 13, 2013 at 0:18
  • @Guy Coder: note that I haven't downvoted the answer. While not exact, this answer is the one I've seen most of the time outside Stack Exchange. Commented Feb 13, 2013 at 0:32
  • @MainMa I didn't say they used using statements. You should avoid the using statements because if two using statements both have a Font type in them you get the same problem of which Font is correct.
    – Guy Coder
    Commented Feb 13, 2013 at 1:11
  • 1
    @RobertHarvey He asked about generated code not people created code. From the code geneation that I have done it is also easier to leave in the full qualifiers than it is to factor out the using statements and reduce. But the reason you leave it in is to avoid the collisons with the names.
    – Guy Coder
    Commented Feb 13, 2013 at 1:23

Short names and usings are useful for humanly written code, because:

  • developers prefer writing var defaultFont = new Font(...) versus var defaultFont = new System.Drawing.Font(...),

  • other developers prefer readable code, not something with long variable names and fully qualified types.

That's why usings were invented in a first place. We could specify fully qualified types, but it would severely reduce code qualify.

Wouldn't it be easier to ditch the long names in generated code? Not really; in fact, it doesn't matter. When the code is generating other code, it makes no difference between type.Name and type.FullName. By using the full names, the code generator doesn't need to prepend the usings, making the generator easier to develop.

I noticed that you commented the answer by Karl Bielefeldt, writing:

That's great if you can treat the generated code as a black box, and never have to modify it. That's not always the case.

Code generators are never designed to generate clean code which would be read and modified by humans. In general, you shouldn't modify generated code, because either you lose the ability to use the generator again, or all your modifications will be lost the next time you call the generator. Case when you do need to modify generated code by hand are rare, and it's understandable that people writing code generators don't take those scenarios into account.

If code generators were written for humans, they would have generated code:

  • With a few more comments,

  • Properly indented,

  • Conform to style guidelines (see yourself how many StyleCop warnings are caused by generated code for a simple Windows Forms class),

  • With clean names which don't start with @ character,

  • Unit tested for regression testing.

This would make the code much more readable, but would also introduce potential bugs and more code to write in support when developing a code generator.

  • Space may be cheap, but it isn't free. I'll bet many of the XSDs that get generated into code can have their size knocked down by at least half with all the fully-qualified attribute class names everywhere. SqlMetal (the LINQ-to-SQL generator) does the same. This stuff adds up after a while. Commented Feb 13, 2013 at 0:25
  • @Jesse C. Slicer: if space is really the concern, generated code should be collapsed to one line, with all whitespace removed and all local variables replaced by a, b, etc. The downside is that such code would be slightly unreadable. Commented Feb 13, 2013 at 0:31
  • 1
    XSDCode has all of the human-readable characteristics you described, but not using statements. Commented Feb 13, 2013 at 0:55
  • @JesseC.Slicer - If a few dozen megabytes of space is a concern there are bigger problems to address.
    – Ramhound
    Commented Feb 13, 2013 at 14:23
  • @Ramhound Deflecting the issue aside, my point is such that generated code can still be human-readable and take up a fraction of the space. Commented Feb 13, 2013 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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