We Keep Coding

C# using object "alias"

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

In c#, is there a compilation penalty when referencing a namespace that doesn't get used? [duplicate]

This question already has answers here:
Why remove unused using directives in C#?
(10 answers)
Closed 9 years ago.
Lately my coworker has been on something of a jihad against line counts. When I check in a new file, I'll generally leave all the referenced namespaces that Visual Studio includes, by default (System, System.Collections.Generic, and System.Linq being the majors that I almost always rely on). Several days later, my coworker will be reviewing diffs, see that maybe I haven't actually used any functions from the .Linq namespace, and he'll clip it. When I come back to the file some days later and want to add some functionality that depends on, say, .Select, my blood pressure shoots up when I see that the namespace is gone and I have to add it back.
My question is: aside from the marginal reduction in the project's line count, or the size of the source files, is there any real gain in clipping these unused namespaces? Is the .NET compiler so poor at analysis that unused namespaces induce a penalty in the outputted assemblies? If he's right in pursuing this madness, I'll accept it as a lesson learned... I just can't imagine that there's any sane reason for this. It seems like nothing but boneheaded craziness to me.

Definitely no benefits comparing to the time spent searching and clipping even though VS has an option to do cleaning. No major benefits except compile time benefits and clean coding.
For more info:
Why remove unused using directives in C#?

There won't be any perfomance boost like ou guess, but removing unwanted using is all about keeping your code clean, neat and readable.
Compiler will make use of only required and related assemblies we using in our code.
Make use of visual studio's Remove unused usings command and to remove unused namespaces to make your code lean and readable to another developer also.

At compile time, only utilised namespaces are compiled into the IL. Those that are unused are ignored.
Aside from a miniscule (and unnoticeable) delay in compilation whilst .Net is figuring out which namespaces you are using there is no impact what-so-ever on the output.

C# using every namespace in the project

In each my .cs file I have tons of "using" lines including other namespaces, like that:
using Game.Models.Main;
using Game.Models.DataStore;
using Game.Manager.MapManager;
using Game.Network.Player;
What if in the beginning of every new .cs file I include "using" statements for all existing namespaces in my code? Are there any downsides of that? Like performance or anything I can't think of?
Why I want that: in Eclipse you can press Ctrl+Space and you'll see the list of definitions starting with the typed characters. In Visual Studio however, you can see that only if the class you're typing is among the "using" namespaces. So when you write a new class you have to type every other class name in full.

It would probably slow down visual studio's intellisense, but as for a compiled product, it would not affect the resulting binary by having superfluous using statements.
If you want to remove superfluous using statements then you can right-click on the using statements, and go to "refactor" > "sort and remove"

There is not much downside except if you ever have classes with the same name in different namespaces (like Color in System.Drawing.Color and System.Windows.Media.Color) than adding all namespaces can either cause compile errors or complete change of behavior of the code.

Normally you only want to include the namespaces you are using. This way you can avoid naming collisions and programmer confusion.
As far as IntelliSense is concerned, if you want something from another name space just start typing in the namespace, IntelliSense will list the namespaces and so you can drill down to what you are looking for.

Centralized Using keyword in C#

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.

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.