This past week, I was working with invoice and order objects and debugging currency conversion rounding issues (I know: fun, right!). Each had a method called getAmount(). The name is nice, short, and snappy. So where is the issue?

Well, this was supposed to express a monetary amount, but as I was reading through the code and trying to debug I started asking myself…

- Does this include taxes or not?

- Is it in my currency or the customer's?

- Are we dealing with cents (integers) or the main currency unit (floats)?

In the early days of programming (e.g. the pre-historic times of the 1980s when I was using a ZX81), memory was scarce, and every character counted. Short variable names were a necessity. But today, text is not the culprit when our storage is full. We have 4K videos for that. There’s no need to be stingy with variable names.

I went through the code and changed the names of the class methods to be more explicit. The getAmount() method, for example, became getAmountPreVatEuroFloat().

Doing so, I discovered several benefits:

• The code was easier to read. Not in terms of logical complexity but of the amount of mental effort needed.

• Certain bugs became clearer to see, e.g. where we were adding things together that just did not make sense.

• And it became easier to debug the AI and autocomplete suggestions

As always, XKCD hits the nail on the head:

Have you encountered variables with confusing or misleading names? I'd love to hear your examples.

Found on the web

I’m taking a closer look at an open-source tool called “Latitude”, designed to help in prompt engineering, tracking changes and evaluating the output. It works as a prompt library and allows you to test outputs against different LLMs.