🔮 Magic Numbers

Let's start with some kind of definition of the magic numbers, here is what Wikipedia says:

A unique value with unexplained meaning or multiple occurrences which could (preferably) be replaced with a named constant.

An example could be TAX Value dangling around few places, which will have to be updated when the law changes.

This problem recurs every time somebody learns programming. It's not a big deal, when you create application for yourself, and it's just something to learn new stuff - when learning there are more important things than that. It becomes a problem, when application is getting bigger, you start to work in a team, or someone else have to maintain it, then questions arise - what that number is.

Magic numbers are much easier to catch, when developing software in a team while working with some control version like Git. Usually all the changes have to be approved by other team members, so more experienced coworkers are able to catch it early on, and correct you.

Git unfortunately doesn't work well with WEBCON applications, so things like pull request would require a lot more work - you won't be able to compare changes line by line. That's why it's important to know how to deal with magic numbers from the beginning.

Enough of theory.

Let's see an example of magic number existing in the wild:

Ah yeah, we are multiplying width by... by what? Let's check the documentation, maybe there we'll find some information.

Not this time.

That example might not be a regular case - it's a number with a lot of decimal places, you won't see a lot of magic numbers like that one hopefully. This value is approximation of the Golden Ratio. To make it easier to whoever will be editing that application later (most likely future you) it is a good practice to name it. Make it a constant.

This way not only it's no longer some magic number, but readability of that expression is much better. You don't have to focus on the digits, you just know it's the golden ratio. That's first benefit.
Second one - you don't have to type that number anywhere else, where you could just do a typo. You are just reusing data you typed in once. If there will be some business requirement to increase the precision - you change it in only one place instead of basically checking everything (if you are working on a colleague's application).

But as I said earlier - those kinds of magic numbers hopefully won't show up often. You'll more likely have to deal with different kinds. I see them a lot while working with data sources.

Let's make a simple example - we are making some application for invoice handling, and attributes on the form should be dynamically shown/hidden based on invoice type. As invoice types are defined, and we know those won't change often - we will use Fixed Values List:

We have our list, now it's time to make some attributes:

We would like to fill data about timesheet only for that type of invoice. This item lists is not necessary for any other type of invoice. So on the Invoice Type on value change we add a form rule:

And there it is - magical number three. At time of developing - you know it's that timesheet invoice, and yeah we are showing/hiding timesheet list, but it's not always this obvious, especially when there are more fields, or more if statements. That's why I'm always creating constant in this case, usually in dedicated group, to make it look like that:

Since I've started working with WEBCON I'm still trying to find a good solution to deal with magic numbers. What I personally don't like in this approach is the fact, that you first define those in Fixed Values List, and then separately in Constants, although it's for sure better than some wild magic numbers.

I hope you won't have to deal with a wizard at your company, who is master of magic numbers, and maybe you won't become that wizard after this post 🙂