Since I wrote a string hash code function recently[1], I was interested to see what they use. Like many, they're using[2] the venerable djb hash. That sent me down a rabbit hole where I discovered that Bernstein was 19 when he wrote about it. Wow.

[1]: https://github.com/munificent/wren/blob/master/src/wren_valu...

[2]: https://github.com/dotnet/coreclr/blob/master/src/mscorlib/s...

From their GetHashCode():

// We want to ensure we can change our hash function daily.

// This is perfectly fine as long as you don't persist the

// value from GetHashCode to disk or count on String A

// hashing before string B. Those are bugs in your code.

hash1 ^= ThisAssembly.DailyBuildNumber;

I'd love to hear the story behind this one :D

The Reference Source site is much easier to navigate. Method names are hyperlinks:

http://referencesource.microsoft.com/#mscorlib/system/string...

Admittedly, I've never been big in C#, but I'm AMAZED by how much repetition string comparison there is.

IE: Environment.GetResourceString("ArgumentOutOfRange_Index")

The string there is in multiple areas of that class, and the same behavior is displayed for all of them. Wouldn't logic suggest everything such as above would be moved in to a constant repository for clarity and also less potential human error for future additions?

And for comparison:

http://grepcode.com/file/repository.grepcode.com/java/root/j...

It's sort of surprising to me how much huger the .NET version is, in terms of code. Virtually all the lines in the Java version are API docs. The .NET version doesn't seem to have them (they must be elsewhere?) but it does have a lot more code and that code is much lower level.

Not sure what that means, if anything, but it's interesting.

That does answer an unanswered question I had on SO about string hashing. If strings are immutable, why isn't the hash code memoized? Seems like it would make HashSet/Dictionary lookups using string keys much faster.