Tales from a code review gone wrong previous: Flatten your architecture: Simplicity as a core value next: New Uber Prof Concept: Cross Session Alerts Originally posted at 2/23/2011Yes, I know that the NHibernate documentation says that you should override Equals and GetHashCode, but I get the feeling that this wasn’t what the documentation authors intended: Comments 02/24/2011 10:19 AM by Dave Mertens This one is a classic. It's also a showcase why code c.q. peer reviews are so important. You catch 'errors' you won't catch with a unit test.. 02/24/2011 02:26 PM by jdn Yeah, it's missing the number 397 in it. 02/24/2011 03:08 PM by Patrick Smacchia R# would have catch it automatically, and would have shown this code grayed in the VS code editor wnd 02/24/2011 04:49 PM by Juan Lopes Even if the base class (e.g. BaseEntity) has a valid logic for calculating GetHashCode based on all identifier properties, NHibernate will complain if the inherited class doesn't implement it. If you're using composite ids, you're oblitaded to do so. That being said, this code may not be so wrong. 02/24/2011 06:09 PM by Piet So is the documentation wrong or the implementer? 02/24/2011 10:01 PM by amiralles A really good one ;-) 02/24/2011 10:09 PM by Alex Simkin @Juan Lopes You are right, S#arp Architecture's BaseObject class implements general purpose GetHashCode. sharp-architecture.googlecode.com/.../BaseObjec... 02/25/2011 10:01 AM by Rob Levine Provided .Equals is implemented by calling down to the base, then this is fine :-D 02/26/2011 03:42 PM by Rian Schmits I have been struggling with implementing Equals/GetHashCode, especially when lazy-loaded properties are part of an object's identity. Because then every time Equals or GetHashCode gets called those properties get lazy-loaded. I have posted a question about this on stackoverflow, but haven't yet received an answer that satisfies me 100%. http://stackoverflow.com/q/5002670/104750 Comments have been closed on this topic.