typeof vs nameof

Skip to end of metadata

• Created by Cullen Tsering, last modified about 5 hours ago

Go to start of metadata

Recently had a discussion with a fellow dev regarding the difference between typeof(T).Name and nameof(T).

It is a lot more performant to use nameof keyword if you are just trying to get the string name of type as opposed to typeof(T).Name.

Let's look at an following example.

Given a simple C# console app as follows:

a console app

1 2 3 4 5 6 7 8

class Program {     static void Main(string[] args)     {         Console.WriteLine(typeof(Program).Name);         Console.WriteLine(nameof(Program));     } }

The compiler generates the following IL:

generated IL

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

.method private hidebysig static void  Main(string[] args) cil managed {   .entrypoint   // Code size       34 (0x22)   .maxstack  8   IL_0000:  nop   IL_0001:  ldtoken    typeof_nameof.Program   IL_0006:  call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)   IL_000b:  callvirt   instance string [mscorlib]System.Reflection.MemberInfo::get_Name()   IL_0010:  call       void [mscorlib]System.Console::WriteLine(string)   IL_0015:  nop   IL_0016:  ldstr      "Program"   IL_001b:  call       void [mscorlib]System.Console::WriteLine(string)   IL_0020:  nop   IL_0021:  ret } // end of method Program::Main

Notice nameof is turned into a string "Program"? while typeof(Program).Name generated code to execute get_Name(). typeof is definitely a runtime evaluation.

Naturally string literal requires almost zero calculation at runtime therefore it is a more performant one.  In conclusion, we should favor it over typeof(T).Name

GIT Config Settings and their Precedence

It is helpful to setup GIT default user name and email so you don't have to type it every time when you push commits to remote.  At the same time, you may have different remote accounts such as github, bitbucket etc. with different user names and emails.  So how do you manage that?  Fortunately, GIT designers have already thought about this.  GIT config command comes with three different options:

$ git config --system user.name "terry yakky" $ git config --system user.email terry@example.com

$ git config --global user.name "barry yakky" $ git config --global user.email barry@example.com

$ git config --local user.name "larry yakky" $ git config --local user.email larry@example.com

--system option

The specified user name and email value apply for every user of the computer on the system and all of the repositories.  The config file is stored at /etc/gitconfig

--global option

The specified user name and email values apply to the current logged in user and all of the repositories under this login.  The config file is stored at ~/.gitconfig (or ~/.config/git/config)

--local option

The specified user name and email values apply to the current repository directory.  The config file is stored at .git/config in the GIT directory.

And the precedence is local trumps global, global trumps system.  If a setting is not found in local, GIT looks for it in global, if not in global, in system.

And this precedence and fallback rule apply to other config settings as well.