Is there a way to make a single "header" type file in C#?
In C++ you had something like "Mainheader.h" that had all of your includes in it.
Is there a way to do something similar for C# where you had a single file with all of your "using" keywords?
Right now I have a bunch of using such as:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Net.Mail;
Is there a way to put them all into a single header file?
No. Using directives only apply to the current source file.
Personally I wouldn't want to do this anyway - the using directives typically give me insight as to the sort of code I'll see in the class, and can indicate a code smell if there are too many disparate ones. (I try to remember to perform "Organize and Sort Usings" before checking in, too.)
Not really. The "mainheader.h" approach worked for C++ because headers are literally textual copy-and-pastes that compilers executed before actually compiling, hence the term "pre-processor directive".
What you may find useful is to create a template that contains some of your most commonly-used directives. Here's a link on how to do it in Visual Studio 2010: http://msdn.microsoft.com/en-us/library/6db0hwky.aspx. You can do it in MonoDevelop as well, but it's a little trickier and involves editing XML directly. Hope this suffices as a workaround.
No this is not possible. The C# compiler doesn't support the notion centralizing using statements in a single file.
Related
// actual
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
// looking for
using Deps.Base; // containing the above
I'm trying to "alias" these objects without additional overhead. Can't find the name for what I'm trying to do, and am wondering if I would be adding overhead with it.
Thanks
What you're planning to do is not possible due to the overlapping/crossing of types sharing the same name in the namespace unfortunately.
There is no way to bundle using statements in C#.
You'll almost never need to look at those statements though. Most IDE's will add them automatically and have procedures to clean them up automatically.
If you use Visual Studio and you don't want to see them you can collapse them.
There are extensions that automatically collapse (hide) them every time you open a cs file:
https://marketplace.visualstudio.com/items?itemName=Nhitze.SeeUsingsLater
I don't have any experience with this extension though. Personally, I'm not bothered by the using statements at the top.
I read somewhere that when you add using System; to your .cs file, the compiler (or maybe something else) adds all System related classes to your .cs file and so maybe it is better to not always add using System; and instead reference your DateTime with its full namespace like this: System.DateTime, for example, if it is easy enough to do and few things reference System it in your .cs file.
Is that true and if so, can that hurt performance or increase the size of the app? If so, I realize that using System; is easier to write and is a convenience and so therefore, you must weigh convenience with performance. It also might be the case that only adding a using System; might not make much difference but when many references are added, maybe it could? Thanks!
Both using directive and full namespace generate the same IL.
It might be very tiny bit of extra work for Language compiler, but you want to sacrifice for readability.
Overview of the compile-time and runtime processes diagram is from Illustrated C# 2012 by Daniel Solis
Mention like
System.Console.WriteLine("Something");
this easy to Understanding purpose Only. But Developer Point of Each Time don't mention fully Qualify Names.
So That Time using Namespaces Using.System
If you use "using System;" you have access to all methods inside the System class.
Your class has a "link" to all of System.
If you write "using System.DateTime;" as example you only have access to the DateTime functions.
In my opinion it is better to use the specified using like "using System.DateTime".
With that you don't have links to "uneccessary" classes/methods in your .cs file.
Also the "using System" does not include all Methods that are inside of the System.
Examples for this are the IO class or the Xml Class.
If you want to use these you have to write "System.IO." before your method call or you have to write using System.IO;
Often files when created start with a set of using statements that are common. Sometimes even after fleshing out the class I have no need of a few of the auto-generated using statements. However, removing them can cause problems if they are eventually needed, such as the problems caused by removing using System.Linq;
Is there a way to tell Visual Studio / Resharper not to complain that certain using statements are redundant?
Example:
using System;
using System.Collections.Generic; // Don't need but want anyway without an error
using System.Linq; // Don't need but want anyway without an error
using System.Net;
using System.Text; // Don't need but want anyway without an error
using Acceptance.EndToEnd.Helpers;
using Acceptance.EndToEnd.Locators;
ReSharper offers a much better way to do this:
You might as well remove them, but as has been pointed out, leaving them in does no harm.
If you do remove them, Visual Studio/ReSharper will add them back in as needed - even System.Linq if you use ReSharper.
If you really want, you can stop ReSharper complaining by turning off this warning when you click on the lightbulb:
You could use ChrisF's answer or you could add ReSharper comments to disable the warnings in your code.
Use
// ReSharper disable RedundantUsingDirective
at the beginning of the file to disable the warnings in the whole file or use
// ReSharper disable once RedundantUsingDirective
using Namespace.That.I.Dont.Need
to disable warnings for single using statements or use
// ReSharper disable RedundantUsingDirective
using Namespace.That.I.Dont.Need
using Another.Namespace.That.I.Dont.Need
// ReSharper restore RedundantUsingDirective
using Namespace.That.I.Do.Need
for multiple namespaces.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why should you remove unnecessary C# using directives?
How is performance affected by an unused using statement
Do unused usings in c# affect runtime performance? If yes, How do so?
using System;
using System.Collections.Generic;
using System.ComponentModel; -----//Unused
using System.Data;---------------//Unused
using System.Drawing;-----------//Unused
using System.Text;-------------//Unused
using System.Windows.Forms;
using System.Threading;------//Unused
using System.Linq;----------//Unused
using System.IO;-----------//Unused
using System.Diagnostics;-//Unused
using System.Data.OleDb;
using OBID;
NO, but It effects the IDE performance and the compilation process of your project.
I can give you a short example. If you have ever used coderush http://devexpress.com/Products/Visual_Studio_Add-in/Coding_Assistance/ which is from devexpress, their IDE optimizer and code optimizer will also suggest you to remove unused namespaces.
Update: Here is more use information from Dmitriy's Blog
There are few reasons why you should remove unused usings in you C# code.
•It is useless code, that just creates clutter in your source code and it also confusing for the developer because you don’t know which namespaces are actually used.
•Over time as your code changes it can accumulate a lot of unused using statements which create even more clutter in you code.
•It can make your compiling faster, since compiler does not have to look up all those extra unused namespaces.
•It will help avoid name conflict with new items that you going to add to your solution if both of those have same names.
•It will reduce number of items in your Visual Studio editor auto completion
There are couple ways to remove those unused usings, you can do it individually on each file
http://msdn.microsoft.com/en-us/library/bb514115.aspx
You also can download plugin called batchFormat for Visual Studio 2010 that can help you to remove all unused usings for the whole project.
http://www.addictivetips.com/windows-tips/batch-format-remove-unused-usings-and-format-visual-studio-document/
No, they do not. In fact, they have no runtime significance whatsoever, regardless of whether they're used or not. They're just a compile-time constant to allow the compiler to recognize types without specifying their full name explicitly.
Their main problem is that a file full of unused usings forces you to make a pointless PgDn when going over the code.
I notice in a lot of C# programs, people use to put a huge list of stuff like:
using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Diagnostics;
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Drawing.Imaging;
using System.Drawing.Text;
using System.Windows.Forms;
using System.IO;
using System.Xml.Linq;
using System.Xml.XPath;
using System.Net;
using System.Web;
What is the advantage of doing stuff like this? I mean I know it lets you shorthand some functions, so instead of "System.Xml.XPath.XElement.Parse()", I can just put "XElement.Parse()". But what other advantages are there? Are there really any advantages besides the short hand?
Are there any disadvantages?
The only thing I can think of besides making the code a lot more readable is this:
using Num = System.Numerics.BigInteger;
Giving short and custom names for specific classes in different namespaces.
Might also help avoiding confusion between classes with the same name in different namespaces.
It's really just the "shorthand" as you mention. The example you give:
System.Xml.XPath.XElement
demonstrates it quite nicely. You're looking to interact with an XElement. That's all. The rest of the fully-qualified reference is just noise. There's no reason to write it over and over throughout the code.
It's just a measure of writing cleaner, more concise, and more expressive code which focuses on the meaningful parts of the logic, as opposed to the structural scaffolding for the compiler.
The idea with namespaces is to qualify a type and this provides a convenient way for doing so. An advantage of including your usings at the top of a file is the short hand and generally translates into more readable code. But disadvantages are that you may end up with conflicting namespaces if types in two namespaces clash. In which case, you can take a look at creating an alias instead.
The using statements provide a sneak peak as to what this code is using as well as providing shorthand access to namespace members. Typically when I'm looking at a new file I'll queue up certain APIs into shorthand memory based off what is included. (This doesn't always work when dealing with sloppy programmers.)