Numbers

Although modern software applications can appear to be processing text or displaying dates or emojis, in fact computers only deal with numbers. Bad assumptions about the mapping between numbers and contextual information such as shopping cart quantities often lead to trouble. Some values, such as a pack of cigarettes costing $23,148,855,308,184,500, are obviously wrong to humans, but to a computer that’s just a number like any other. Some perfectly valid numerical values, such as 0, might make no sense when used as contextual information, such as characters on screen. Some contextual information requires a particular sequence of numbers, such as Unicode combinations, but computers will happily store and transmit invalid numerical sequences.

Here are some ideas around amounts and quantities to remember when developing software:

Don’t assume you can apply trivial mathematical rounding to fractional amounts. There are specific rounding and truncation rules for financial information, and they vary by country.

Not all currencies use two decimals. For example, Japanese yen don’t use decimal fractions. Kuwaiti dinar have three decimals.

Try amounts with and without decimal places, and with varying number of decimals.

There’s no universally agreed standard for writing currency amounts (or if there is, normal people don’t obey it). Expect users to input currency amounts inconsistently. To a person, 5000, $5,000, $5 000 and $5,000.00 mean the same thing. If you want consistent information, make sure to check for a particular format.

People in different countries use different separators for thousands and decimals. The US number 1,234.56 would be 1 234,56 in France. Don’t just remove all the commas before turning a string into a number.

Try negative values where they’re not expected (–1 books).

Don’t assume quantities always need to be positive. In some business domains, it’s perfectly acceptable to have a negative quantity (for example, to mark items returned by customers).

Avoid using special values to mark missing information (such as 0 or No Plates), as this can be interpreted as the actual value by someone else.

Avoid marking test data with special values (such as having a surname Test), as this can easily create false positives. It’s best to have specially identified accounts for testing, which you can later clean up.

Explore rounding strategies, especially with things that accumulate over time. Small rounding errors can create a big mess.

With Unicode, memory length and screen length aren’t necessarily related. Some Unicode symbols are very long ( (0xFDFD), some are invisible (0x200B), and some combine with previous characters (0x0597).

Check how the contextual data gets recorded and test around the corresponding numerical boundaries. For example, test what happens when the timer reaches the end of a 32-bit number range.

The number 0 is often interpreted as false information or missing data, or is just not expected in mapping to contextual values. Test what happens when your data maps to 0. Remember the 787 Dreamliner engines that would shut down when the control timer reached zero.