What is a good way to indicate that a number is not something you can count with?

Question

What is a good way to indicate in programming that the sequence of digits you see is not a value you can do math on?

I use a lot of numbers which aren't "numbers". From account-numbers to patient-id numbers country codes to the codes for human sexes.

What I want to prevent is that others put those "numbers" into an integer data type.

Why? Because what might be a "number" now, may not be in the future: for instance the patient-id may now only contain numbers but we can have a situation where that changes to containing a Letter.

Also when you put "013" into an integer, you lose the leading 0 which leads to loss of information and subtle bugs.

How can I communicate this clearly?

Answer 1

You can use a wrapper class/struct around your string to communicate the intent of the value. It will also allow you to validate inputs and achieve compile time safety, depending on the language you use. Or even completely hide the wrapped value. Here's a reasonable example on how to do it in C#

public class PrimaryAccountNumber
{
    private readonly string Value;

    public PrimaryAccountNumber(string value)
    {
        //validations
    }

    public void WriteTo(Stream stream)
    {
        //...
    }
   
}  

You can go further with inner classes, depending on what you want/need/are required.

public class PrimaryAccountNumber
{
    private readonly string WrappedValue;

    public PrimaryAccountNumber(string value)
    {
        //validations
    } 

    public class StreamPanWriter
    {
        private readonly Stream _stream;

        public StreamPanWriter(Stream stream)
        {
            _stream = stream;
        }

        public void WriteTo(PrimaryAccountNumber value)
        {                
            //the wrapped value is visible here
        }
    }       
}  

Answer 2

It sounds like you are already using string data types for these numbers (maybe in a data model or UML model or some code), but you want to prevent another dev to convert those strings accidentally to a number data type, because they ignored the original type or missed to read the documentation.

For this, my best recommendation is to write some automated tests (maybe integration tests) where you deliberately use some non-number values as test data. Design the tests in a way they will break when someone starts to use a number data type for processing those values.

And hope that other devs are smart enough to get the message and do not just "fix" the breaking tests by changing the test data.

Answer 3

What you're dealing with here is a non-technical problem, it's a human one.

There are technical solutions to be found here, but they don't cover the problem in its entirety. To repurpose an old saying, the universe will eventually come up with a bigger idiot that foils your clever technical hurdle.

I'm apprehensive of solving this using a technical hurdle because your attempts at protecting yourself from bigger idiots will take more and more effort and time, on top of likely detracting from the readability and simplicity of your codebase.

So this answer is going to offer some lateral solutions:

Option A - Since you say that the ID content might change in the future to be non-numeric, why not get ahead of the curve and already turn it into a non-numeric value? It stops anyone with numeric intentions dead in their tracks. Even just adding an otherwise ignored prefix (turning 123 into A123) would suffice.

Option B - If you can't just use non-numerics in production right now (for whatever external reason), if you can control the testing layer you can still intentionally throw in some non-numeric values to test with and see if it breaks.

Option C - If your concern is that developers on your own codebase might make this mistake in the future, I'm worried about the team's trust in one another. If you know that this ID is non-numeric, so should the rest of the team. For trivial mistakes, there's the code review process to catch them. For endemic misconceptions, this seems like a team leadership or mentoring problem to solve - and if the issue is at this level, you're probably going to have more issues of a similar kind.

Option D - If your concern is that other dev teams working in other applications are going to misuse your identifier types, that's on them, not on you. You cannot control what others do, that's why they're a different team than you.
If you clearly document that this field can contain non-numeric characters, then they suffer the consequences of not reading your documentation when their numerical data type breaks once your ID values start changing.

Option E - I guess this is a somewhat technical one. People make bad calls because they're looking for the path of least resistance. If you make the correct path the path of least resistance, then you will find that people naturally gravitate towards doing things the way you want them done.
For example, you could provide a Nuget/npm/... package which provides all the data contracts and maybe even a neat and easy-to-use HTTP client. People will want to adopt it if it saves them the effort of having to do this work themselves, and you can sneakily make sure that they're using the contract the way you intended for it to be designed.
There's no guarantee that they will use your package (like I said before, you cannot control how others consume your service), but it will significantly mitigate the problem. The bigger the idiot, the more likely they will take the path of least resistance (blindly), which tends to mean that the worst offenders are the ones using your package.

Answer 4

Use a string datatype, and maybe communicate permissible values in the documentation using regular expressions.

Answer 5

What you have are identifiers that just happen to be numeric. If you type them as identifiers, not numbers, then nobody is ever going to confuse the two.

There is of course no way to prevent developers from intentionally misusing your identifier as a number, but given that you've honestly done your best to prevent such misuse, these cases simply aren't your problem. A bad developer will always find a way to break the most idiot-proof code; you should write your code to be used by people with common sense, not idiots.

Answer 6

For example, create a class PhoneNumber and a class CreditCardNumber (careful about storing the latter), obviously without any method to turn it into a large integer. That prevents people from doing a lot of stupid things.

You would at best have methods to create a string representing the object, possibly in multiple formats, and locale specific. For example you display a phone number with or without country code depending on whether the country code matches the user’s country. Or you might have spaces between groups of digits in a credit card number. And a tiny image of the credit card might be nice.

If another developer is stupid enough to extract the digits from a phone number, drop a leading “+” and/or zero, that’s not your problem.

Answer 7

I use a lot of numbers which aren't "numbers". From account-numbers to patient-id numbers country codes to the codes for human sexes.

Strictly speaking, Users can't work directly with Numbers. Or Dates.
Not what a Computer or a Database considers to be a Number or a Date, anyway.

Such data gets stored according to IEEE specifications, of which Users know nothing and haven't been able to enter into machine memory locations since we used mechanical switches on physical machines to do so.

Users always work with a Character Representation of Data. The sort of thing that they can type from their keyboard.

Any data that comes into your Application / Database needs to be stored in the appropriate Data Type.

• If it's a [countable] number, then it should go into a numeric Data Type.
• If it's a date value, then it goes into a Date Data Type.
• Pretty much everything else goes into a Character Data Type.

This "inwards" formatting for storage eliminates your "loss of information and subtle bugs". The converse, "outward" formatting for display, makes sure that the data is presented to the User in a form that they are comfortable with (UTC datetimes might be great for Applications, but not many people choose to work with them!)

If Developers choose to write SQL that compares numeric and character data, then they will have to explain and/or correct the abysmally poor performance that they get from such queries, or the strange results they get, with [character] data being "incompletely converted" into numbers by some DBMSes.

Answer 8

Write a random generator for each class of such values (making sure that it can at least in theory output every valid value), then use the generators everywhere you need an arbitrary such value in tests. This

• ensures tests fuzz any code which deals with such values,
• clarifies in which tests the actual values are relevant (they are fixed rather than random), and
• if anyone tries changing a generator this should stand out very explicitly during code reviews.

For example, you could have a random credit card number generator. It should return a string (if your language even distinguishes them from numbers in a useful way) with a random valid value. If someone for example changes the code to return a number it'll probably break tests whenever the value is less than 1000_0000_0000_0000, since any such integer, when treated as a string anywhere in your code, will have the wrong length.

For a bunch of examples, see these tests.