Why do lowercase and uppercase versions of string exist and which should I use? [duplicate]

Question

Okay, this may be a dumb question, but I've not been able to find any information on it.

Are String.Empty and string.Empty the same? I always find myself gravitating towards using the upper case version (String.Empty) because I prefer the color and look of it in my IDE than the lower case version (string.Empty)...

Is there a "correct" way to use these that differ or is it entirely down to personal preference? It was my assumption that they're both the same, but to be honest, I never gave it any thought until for whatever reason today I wondered "If they both exist, they must both exist for a reason".

Is there a reason that anyone knows of? If so, what is it? Can anyone enlighten me?

P.S. The "exact duplicates" only answer half of the question - "which is right?", not the "why do they both exist?"

---

Exact Duplicate: What is the difference between String and string in C#?

Exact Duplicate: String vs string in C#

Answer 1

In C#, lower-case type names are aliases for the System.xxx type names, e.g. string equals System.String and int equals System.Int32.

It's best practice to use these language aliases for the type names instead of their framework equivalent, for the sake of consistency. So you're doing it wrong. ;-)

As for a reason why they both exist, the .NET types exist because they are defined in a language-independent standard for the .NET libraries called CTS (common type system). Why C# defines these aliases is beyond me (VB does something quite similar). I guess the two reasons are

1. Habit. Get all these C and Java programmers to use C# by providing the same type names for some fundamental types.
2. Laziness: You don't have to import the System namespace to use them.

EDIT Since many people seem to prefer the other notation let me point out that this is by no means unreasonable. A good case can actually be made for the usage of the CTS type names rather than C#'s keywords and some superficially good arguments are offered in the other answers. From a purity/style point of view I would probably concur.

However, consider if this is worth breaking a well-established convention that helps to unify code across projects.