We Keep Coding

What will happen if using namespace but not used in C# [duplicate]

Visual Studio will automatically create using statements for you whenever you create a new page or project. Some of these you will never use.
Visual Studio has the useful feature to "remove unused usings".
I wonder if there is any negative effect on program performance if the using statements which are never accessed, remain mentioned at the top of the file.

An unused using has no impact to the runtime performance of your application.
It can affect the performance of the IDE and the overall compilation phase. The reason why is that it creates an additional namespace in which name resolution must occur. However these tend to be minor and shouldn't have a noticeable impact on your IDE experience for most scenarios.
It can also affect the performance of evaluating expressions in the debugger for the same reasons.

No, it's just a compile-time/coding style thing. .NET binaries use fully qualified names under the hood.

The following link A good read on why to remove unused references explains how it be useful to remove unused references from the application.
Below are the some excerpts from the link:
By removing any unused references in your application, you are
preventing the CLR from loading the unused referenced modules at
runtime. Which means that you will reduce the startup time of your
application, because it takes time to load each module and avoids
having the compiler load metadata that will never be used. You may
find that depending on the size of each library, your startup time
is noticeably reduced. This isn't to say that your application will
be faster once loaded, but it can be pretty handy to know that your
startup time might get reduced.
Another benefit of removing any unused references is that you will
reduce the risk of conflicts with namespaces. For example, if you
have both System.Drawing and System.Web.UI.WebControls referenced,
you might find that you get conflicts when trying to reference the
Image class. If you have using directives in your class that match
these references, the compiler can't tell which of the ones to use.
If you regularly use autocomplete when developing, removing unused
namespaces will reduce the number of autocompletion values in your
text editor as you type.

No effect on execution speed, but there may be some slight effect on compilation speed/intellisense as there are more potential namespaces to search for the proper class. I wouldn't worry too much about it, but you can use the Organize Usings menu item to remove and sort the using statements.

Code that does not execute does not affect the performance of a program.

No, there are several process involved when compiling a program. When the compiler start looking for references (classes, methods) it will use only the ones used on the code. The using directive only tells the compiler where to look. A lot of unused using statement could maybe have a performance issue but just at compile time. At runtime, all the outside code is properly linked or included as part of the binary.

c# using declarations - more = good or bad?

edit typos
Hi,
This is possibly a moronic question, but if it helps me follow best practice I don't care :P
Say I want to use classes & methods within the System.Data namespace... and also the System.Data.SqlClient namespace.
Is it better to pull both into play or just the parent, ie...
using System.Data
using System.Data.SqlClient
or just...
using System.Data
More importantly I guess, does it have ANY effect on the application - or is it just a matter of preference (declaring both the parent and child keeps the rest of the code neat and tidy, but is that at the detriment of the application's speed because its pulling in the whole parent namespace AND then a child?)
Hope thats not too much waffle

It doesn't make any difference to the compiled code.
Personally I like to only have the ones that I'm using (no pun intended) but if you want to have 100 of them, it may slow down the compiler a smidge, but it won't change the compiled code (assuming there are no naming collisions, of course).
It's just a compile-time way of letting you write Z when you're talking about X.Y.Z... the compiler works out what you mean, and after that it's identical.
If you're going to use types from two different namespaces (and the hierarchy is largely illusional here) I would have both using directives, personally.

Click Organize->Remove Usings and Visual Studio will tell you the correct answer.

Firstly, it has no effect on the application. You can prove this by looking at the CIL code generated by the compiler. All types are declared in CIL with their full canonical names.
Importing namespaces is just syntactical sugar to help you write shorter code. In some cases, perhaps where you have a very large code file and are only referring to a type from a specific namespace a single time, you might choose not to import the namespace and instead use the fully-qualified name so it's clear to the developer where the type comes from. Still, though, it makes no difference.

Express what you mean and aim for concise, clear code - that's all that matters here. This has no effect on the application, just on you, your colleagues and your future workers brains.

Use whatever happens when write your type name and press Ctrl + .,Enter in VS.

Use of the using keyword in C#

In my background in C++ I was a supporter of using the scope resolution operator, for example
class Foo
{
std::list<int> m_list;
...
}
for external libraries, to keep clear which library you were using.
Now in C# I don't know if there's a rule of thumb or a best practice to know which packages should be included via the using keyword and which classes should be fully qualified. I suppose that this can be a subjetive issue, but would like to know the most extended practices.

I pretty much never fully qualify names - I always use using directives instead.
If I need to use two names which clash, I'll give both of them aliases:
using WinFormsTextBox = System.Windows.Forms.TextBox;
using WebFormsTextBox = System.Web.UI.WebControls.TextBox;
That rarely comes up though, in my experience.
I tend to make autogenerated code fully qualify everything though, just for simplicity and robustness.

I think the saving grace in C# is the directives are fully constrained to the file you place them in. I use them whenever their use is clear for the code in the file and it helps readability of the code. Another team at my office doesn't use them at all - I think it's nuts but they came up with their own rules and are happy with them.

Tend towards whatever makes the code more readable and understandable.
If the name may be ambiguous and their is no common "most likely case" then fully/partially qualifying to make this clear can be sensible even if this increases verbosity.
If confusion exists but one candidate is far more likely then qualify only in those cases where you do not use the most common case.
Common example is the use of System.Collection.X classes rather than the System.Collections.Generics versions (perhaps for back wards compatibility). In this case importing the generic namespace is fine and any non generic ones are fully qualified.
This makes it clear where you are using legacy code.
If you will be dealing with multiple clashes and the resulting full qualification would make you code extremely unreadable then it may make sense to use aliases to separate them out but you should be pretty averse to doing this since it renders the resulting code easier to physically read but harder to conceptually understand.
You have injected an element of inconsistency with the wider world. this makes code snippets within the class harder to understand in isolation.
If you must do this consider alias names which make it very clear that these are aliases as an indication to readers that they should look at the using statements for confirmation of the real types.

Does including an entire namespace slow things down?

Is there any evidence that suggests including a whole namespace in c# slows things down?
Is it better to do this
System.IO.Path.Combine....
Or to include the whole System.IO namespace?

It's much better to include the namespace in a using statement at the top of your class. The compiler doesn't care; it will emit the same IL both ways, and your code will be shorter and easier to read.

No matter what, including the entire namespace will not slow down production code.
Will it slow down the compiler? That's debatable, but C# compilation is so fast it's unlikely. A far worse offender in slowing down compilation is a large number of projects in your solution.

It makes no difference... it's purely for readability and in cases where you have naming collisions.

It will not slow down your production code, however it could slow down your coding as the IDE has to show you more options and you have to pick through more possibilities when looking at code completion lists.

Adding extra namespaces can affect the compile time of your application. It's unlikely to be noticable in most applications but extremes could make it visible.
It however has no impact on the runtime performance of your application.

No, the compiler is fast enough. Not sure what else I can add :)

What are the benefits of maintaining a "clean" list of using directives in C#?

I know VS2008 has the remove and sort function for cleaning up using directives, as does Resharper. Apart from your code being "clean" and removing the problem of referencing namespaces which might not exist in the future, what are the benefits of maintaining a "clean" list of using directives?
Less code?
Faster compilation times?

If you always only have the using directives that you need, and always have them appropriately sorted, then when you come to diff two versions of the code, you'll never see irrelevant changes.
Furthermore, if you have a neat set of using directives then anyone looking at the code to start with can get a rough idea of what's going to be used just by look at the using directives.

For me it's basically all about less noise (plus making Resharper happy!).
I would believe any improvement in compilation time would be minimal.

There's no runtime impact. It's purely compile time. It potentially impacts the following:
Less chance for Namespace collisions
Less "noise" in the code file
Very explicit about which namespaces and possible types to expect in the file
Using the menu to remove unused and Sort means more consistency with using statements among the devs. Less chance of dumb checkins just to fix it up.

Less noise.
Clear expectation of what types are used ("My UI layer depends upon System.Net. Wow, why?")
Cleaner references: if you have the minimal set of using statements, you can cleanup your references. Often I see developers just keep throwing references into their projects, but they never remove them when they're no longer needed. If you don't have anything that actually needs a reference (and a using statement counts), it becomes trivial to clean up your references. (Why would you want to do that? In large systems that have been decomposed into components it will streamline your build dependencies by eliminating the unused deps.)

For me, a clean list of using statements at the beginning can give a good understanding of the types to expect.

I saw a decent gain in compile time a few years ago when I first installed ReSharper (on an 18 project solution). Since then its just been about keeping it clean.

I can't speak to the benefits in compile time and performance, but there's a lower chance of namespace collisions if you have minimize your using declarations. This is especially important if you are using more than one third party library.

There is one compile-time difference: when you remove a reference, but still have a using directive in your code, then you get a compiler error. So having a clean list of using directives makes it a little bit easier to remove unused references.
Usually the compiler removes unused references, but I don't know if that works when a using is in the code.