Coding Guidelines
Today I had a really good conversation with two of my co-workers about object oriented coding guidelines. Two guidelines happened to really stick out in the conversation.
First and foremost, never return a null value from a method (or interface). Returning null values seems to stem from the days when programmers dealt with C code. This seems to have been the proper way to code back in the day because objects tended to be quite heavy when it came to memory and CPU utilization. Returning null in object orientated languages causes mistrust in your code because any caller of your method must check for null values before using the returned value. If the caller doesn't check for null values then an exception will be thrown which will cause a great deal of instability in your application.
Second, if it is possible, wrap primitives in objects. The tendency that many people have when passing primitive values around in code is assuming something about the primitive in the boundary cases. This can be thought of as metadata that should be attached along with the primitive value. There is almost always some kind of metadata that should be attached to primitive values that will help improve your code. This will help users of your interface (this term is used loosely here) use your value in the correct way. For example, let's say you pass around a float value that is a lengh value. Instead of just passing this float value around, wouldn't it be better to also pass along the units of measurement as well, such as metres or feet.