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.
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.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,
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
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.