Hash This!
In .NET programming, overriding Object.GetHashCode() has always seemed excessively painful to me. I always have to look up the rules, and then it seems to take forever to figure them out, and I always feel like I've probably gotten something wrong. So when I ran into Ian Griffiths' post, I at least felt like I was in good company. Judging by what Ian says, the documentation is wrong. GetHashCode() should return the same value if 2 objects are Equal (i.e. Assert.IsTrue(o1.Equals(o2) && o1.GetHashCode() == o2.GetHashCode()), and the hash codes should be randomly distributed among all inputs. The 2nd seems difficult to test, but those are the rules. Java has this same restriction. The funny thing is that Wikipedia gives the same advice for Java:
A further contract that the map has with the object is that the results of the
hashCode()andequals()methods will not change once the object has been inserted into the map. For this reason, it is generally a good practice to base the hash function on immutable properties of the object.
Which is to say, overriding Equals in a useful way on an object with mutable properties or fields is not advisable.
What bothers me about this entire thing is that as far as I can tell, GetHashCode() exists for one reason: System.Collections.Hashtable. Maybe I'm just being a purist, but this seems to be quite ridiculous: forcing every object in the system to create a contract with one object that may not even be used in the program (at least knowingly), in exchange for the quite useful ability to assert whether two objects contain the same values. When you look at languages that are positively hashtable crazy (Ruby, Python, etc.), you don't have that requirement.
— Gordon Weakliem at permanent link
Configure What's Worth Configuring
Richard Newman makes a point on configuration that's worth noting:
If I need to change something, it's quicker to change the code and redeploy than it is to change the XML and redeploy, and there's less to go wrong.
This is really true. Configurable values are essential for things like allowing for test vs. production deployments, or for deploying different versions of a site (a branded portal, or whatever), but configurable values that for practical purposes are constants are just a headache - for development and for operations.