A Float is NOT a Currency

Do not use floats when representing currency.This is just asking for trouble.

Anytime you have to deal with floating point representations you can always get unpredictable results. I cannot count the number of times I have seen the "phantom penny" situations where balances are a penny off and you end up spending half a day with your accountant hat on trying to find where the penny went. You look and look and then you realize that somewhere in the code someone used a float inside the calculation. You change the variable type and your penny "magically" appears.

There are many alternatives in the modern programming languages for representing currency and they should be used. If those are not available, you can always go old school and use the int primitive type to represent currency.

Breaking the Law...

Today I read a great post by Phil Haack on the Law of Demeter. I think I had read about it before, but it never sunk in until today. As I read it I had that uneasy feeling you get when you realize you have been unknowingly doing something you are not supposed to do.

The Law of Demeter is pretty simple:

A method of an object should invoke only the methods of the following kinds of objects:
1. itself
2. its parameters
3. any objects it creates/instantiates
4. its direct component objects

Essentially it means that in languages like Java you should not chain together method calls using the dot operator. A great example of this is detailed in the paper, The Paperboy, The Wallet,
and The Law Of Demeter by David Bock. Bock goes through a perfect illustration of why the Law of Demeter should be followed, with an emphasis on scenarios where not using it can cause null pointer exceptions. Sadly, this is the exact case I ran into recently that would have been avoided if I had followed the law.

I had a client interface that needed to get information contained in an object returned from a different method. The needed information was always to be in the first item in a collection, so I immediately used dot operator chaining to get the iterator for the collection and then the first item in the collection.

Item i = (Item)object.methodReturningCollection().iterator().next();

Looking at that code now I see how naive I was being when I wrote it. I never thought of the scenario where the initially called method would return as null . Of course this was caught in testing, but was fixed by simply using a temporary variable and testing for null. This fixes the problem with the null object, but still goes against the law. What I should have done was to create a method in the called object that returned the information I was trying to obtain in the client code. Then the client would not need to know how to retrieve the information as it should be the responsibility of the called object.

I consider myself a fairly decent developer, but you learn something new everyday. I will now be looking out for this when I am doing refactoring. It's amazing to me how much software development is an ongoing learning experience. I love every minute of it...

New Beginnings

I decided to change the name of the blog to be more relevant to me (and to rid myself of the possibility of getting a stink message from the Dilbert folks if this blog ever picks up any traction). I have some crazy things going on at home right now as I am preparing for a new addition to the family that will be here soon, but I will soon be giving this blog the attention that it needs. I am starting with the look and feel and with that I have already created a new feed for this blog:

http://feeds.feedburner.com/MrWillSoftware

In about a month I am going to turn off the original feedburner feed, so be sure to update any RSS readers you are using.

World Class Computer Science Courses for FREE!!!

For those of you who do not know, MIT and Stanford both offer free computer science courses. they are comprised from courses in previous semesters and in some cases the current semesters. They cover many topics and provide you to get some world class education at the price of $0.00. Can't beat that... Just try the links below.

MIT Computer Science Courses

Stanford Engineering Everywhere

Stanford on iTunesU

If there is enough feedback, I would be very much open to starting an online study group to go through some of the contents in particular classes.

Reviewing Requirement Specs for New SW Devs

One of the most difficult things for new software developers to do is to review a requirements specification for a new feature or module. Too often they simply read through the spec and do not bother to question it. This would be fine if all specs were complete when they reached the developer's hands, but this is usually not the case. In this case, it becomes the developer's job to ensure the spec finds its way to completion by raising any concerns. This is where the Requirements Checklist in Code Complete comes into play.

The Requirements Checklist is not a list of things that must all be present, but they create a nice guide for checking the completeness of specifications. You should apply these questions to any requirements specification you receive and if the answer is no to any of them, you should question the writer as to why.

Here is a snippet of the checklist with some explanations as to why they are important. The rest of the checklist can be found on the Code Complete site (http://www.cc2e.com/0323).

Specific Functional Requirements

• Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
• Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
• Are all output formats specified for web pages, reports, and so on?
• Are all the external hardware and software interfaces specified?
• Are all the external communication interfaces specified, including handshaking, error-checking, and communication protocols?
• Are all the tasks the user wants to perform specified?
• Is the data used in each task and the data resulting from each task specified?