views:

62

answers:

3

Where I work, I often see code like that :

public void Test(Models.User.UserInfo userInfo, Models.User.UserParameter param)
   { ... }

Personally, I prefer to see something like that :

public void Test(UserInfo userInfo, UserParameter param) { ... }

And have an import at top.

What you think about this ? What the best practices ? What the pro and cons of both ? How could I convince my teammates ?

I find second option to be more clear.

+5  A: 

Definitely use the using directive, IMO. Typically this is just code that has been autogenerated by Visual Studio. I haven't seen anyone deliberately write code like this manually. IMO it's worth making sure that all code that humans will read looks like humans wrote it - so I'd add the using directive and reduce the names here. It makes it much easier to read - particularly when the namespaces are long.

Jon Skeet
Agreed. There are times when the name will probably be fully qualified if the name is ambiguous between two using directives, but that can also be solved with aliasing in the directives. The choice between aliases and fully-qualified names is left to the developer as to which is more clear and natural to someone supporting that code.
David
Which brings about an interesting follow-up question: why can't autogenerated code use the `using` directive? Is it allergic to it?
Jesse C. Slicer
@Jesse: I'm not sure why designers don't tend to generate using directives. I'd like it if they did, too...
Jon Skeet
@Jesse: In case of naming conflicts. (For example, if your namespace has a class that conflicts with a standard .Net classname)
SLaks
@SLaks: Hm. A good point. I'm getting thinky about this now. It would be nice if there were a happy medium. The output from xsd.exe alone makes me cringe.
Jesse C. Slicer
@Jesse: While it would be possible to only use `global::` for conflicts and use usings elsewhere, it would be extremely complicated, and require the compiled binary of the DLL you're putting it into. Plus, it could break if you introduce a new class. I'm working on a project right now that has a _class_ (not mine) called `System`.
SLaks
@SLaks: Someone needs to hang for that level of egregious naming.
Jesse C. Slicer
A: 

I tend to use the fully qualified name if the type is only used once or maybe twice in a code file. For everything else I use using

But this also depends on the length of the full name. It's all about writing beautiful, easy to read code.

Jesper Palm
A: 

In all but a few circumstances, I'd say, import or using the namespaces is the best practice. This has the added advantage of early degradation: the compiler will complain if it cannot find the namespace.

Among the few circumstances where the fully qualified name is needed (to be more correct: it is not fully qualified, you do not specify the version or key) are where name collisions would occur (i.e.: when two namespaces happen to have the same name, I see this happen often with the Util classes that many vendors add to their libs) (note that you can alias class names using using). Or when you need to qualify the name as a string, but that's another use-case (i.e., with reflection). Occasionally, while debugging, it helps to use the FQN, because the debugger does not allow adding a using directive.

In the event you use the name only once, you may be tempted to use the FQN, but in my experience, you'll quickly find yourself using more than one name of the namespace and refactor it to importing the namespace in the header.

Abel