string
is an alias in C# for System.String
.
So technically, there is no difference. It's like int
vs. System.Int32
.
As far as guidelines, it's generally recommended to use string
any time you're referring to an object.
e.g.
string place = "world";
Likewise, I think it's generally recommended to use String
if you need to refer specifically to the class.
e.g.
string greet = String.Format("Hello {0}!", place);
This is the style that Microsoft tends to use in their examples.
It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.
There is actually a (subtle) difference between the two. Imagine you have the following code in File1.cs:
// File1.cs
using System;
namespace Outer.Inner
{
class Foo
{
static void Bar()
{
double d = Math.PI;
}
}
}
Now imagine that someone adds another file (File2.cs) to the project that looks like this:
// File2.cs
namespace Outer
{
class Math
{
}
}
The compiler searches Outer
before looking at those using
directives outside the namespace, so it finds Outer.Math
instead of System.Math
. Unfortunately (or perhaps fortunately?), Outer.Math
has no PI
member, so File1 is now broken.
This changes if you put the using
inside your namespace declaration, as follows:
// File1b.cs
namespace Outer.Inner
{
using System;
class Foo
{
static void Bar()
{
double d = Math.PI;
}
}
}
Now the compiler searches System
before searching Outer
, finds System.Math
, and all is well.
Some would argue that Math
might be a bad name for a user-defined class, since there's already one in System
; the point here is just that there is a difference, and it affects the maintainability of your code.
It's also interesting to note what happens if Foo
is in namespace Outer
, rather than Outer.Inner
. In that case, adding Outer.Math
in File2 breaks File1 regardless of where the using
goes. This implies that the compiler searches the innermost enclosing namespace before it looks at any using
directive.
Best Answer
Use SHA-2. Always. SHA-1 shall be reserved to situations where SHA-2 cannot be used due to interoperability issues with legacy code.
There is no performance issue until actual measures have been performed. Hash functions are fast. In most situations, hash function performance has only negligible impact; even detecting it could prove difficult. Security comes first. Since weaknesses have been found in SHA-1, using it nonetheless requires some robust justification. Using SHA-256 will not be questioned; this is the "default choice". But if you use SHA-1, prepare to be criticized.
Note that there are four functions known as "SHA-2": SHA-224, SHA-256, SHA-384 and SHA-512. SHA-224 and SHA-256 are the same function, save for an internal parameter (the "initial value") and the output size (SHA-224 output size is 28 bytes, whereas SHA-256 offers 32 bytes); they have the same performance characteristics. Similarly, SHA-384 and SHA-512 are the same function performance-wise. SHA-512 uses 64-bit arithmetic operations and is faster than SHA-256 on platforms which offer 64-bit opcodes; on 32-bit platforms, SHA-256 will be faster (note: on 32-bit x86 with native code, it is possible to use the SSE2 opcodes and their 64-bit computing abilities, hence some native code implementations of SHA-512 will be faster than SHA-256 in 32-bit mode; the OpenSSL code does that; but, as far as I know, the SHA-512 implementation in .NET is "managed code"). Also, all the SHA-* functions have some basic granularity, because they process data by chunks: for SHA-256, chunks are 64-byte long, whereas SHA-512 uses 128-byte chunks; when hashing very short data elements, the higher SHA-512 granularity correspondingly lowers its performance. Finally, SHA-256 (on a 32-bit platform) is likely to yield smaller code (i.e. use less L1 cache on the CPU).
So, when in doubt, use SHA-256. If you plan on using SHA-1 then you should doubt.
If you want to use a hash function for a non-cryptographic usage (i.e. the weaknesses are not a problem for you) then, instead of SHA-1, consider MD4.