Don’t use floats and doubles in Java to represent Money values (or anything where you need exact values)

Float and double types in Java are approximations – they don’t represent exact values. This is by design to allow faster calculations of approximate values at the cost of exact accuracy.

If you are new to Java, at some point you will run into this, or you’ll come across someone else you work with who may tell you to never use floats and doubles to represent Money, but maybe you’re not sure why. The reason is because of how floats and doubles represent approximate values.

If you’ve never come across this before, try this experiment:

float result = 0.01f + 0.01f + 0.01f;

You would expect this calculation to represent 0.03, but if you compare the value of result with 0.03f you’ll find this snippet of code unexpectedly prints false:

if(result == 0.03f){
    System.out.println("true");
}
else{
    System.out.println("false");
}

To represent accurate floating point values use BigDecimal. Alternatively, money values can be represented as an integer value in cents or pennies (for example) to avoid the approximation issues.

tldr; Don’t use floats and doubles to represent money values in Java.

Essential best practices and principals of effective software development

The software development industry is full of best practices and recommendations, many that evolve and change as our technology changes. There are some core concepts that remain beneficial even though programming languages and runtime technology platforms have changed over time.

Here’s a summary of some core principals that can help us develop software systems more effectively:

KISS – Keep it Simple, Stupid

Unnecessary complexity in code is technical debt that will to cost you at some point in the future – it’s more likely to contain unexpected and hard to find bugs, and complicated code it harder to understand, and therefore harder to maintain. Keep it simple.

DRY – Don’t Repeat Yourself

Avoid duplication in code. Duplicated blocks of code are a maintenance risk. If there is bug in a block of code that exists in multiple places, fixing the issue in only one place means that the issue still remains in those other blocks of code. When other developers are maintaining the code in the future, it may not be obvious that the same code exists elsewhere.

YAGNI – You aren’t gonna need it

The cost of maintaining a system increases in relation to the more code that is part of your product or solution. Why? Because the more code you have, these’s a higher risk for things to break, go wrong, increased effort for testing, and so on. You won’t have bugs in code you don’t have (you may have missing features but that’s a different problem). It makes sense therefore that you shouldn’t build additional features that you or your customer doesn’t need or want. The YAGNI rule is that if you don’t need it, don’t build it. Don’t make your job harder by increasing the possibility for things to break, or increasing the overhead of maintenance by building unneeded features that need to be fixed, updated, tested in the future. Don’t write code you don’t need.

Design/plan/structure your code to enable easier unit testing

Not everyone agrees whether Test Driven Development (TDD) should be followed as an absolute rule or not, but thinking about your tests first has a benefit that can be taken and used to your advantage even if you don’t subscribe 100% to the TDD approach. If you think about structuring your code in a way that makes it easier for you to test, then it’s immediately easier and takes less effort to write your unit tests, compared to code where there was no effort or thought into how the code could be tested. Simpler code is (usually) easier to test, compared to overly complex code that is usually much harder. Simpler code is easier to understand and maintain.