Primitive obsession – why you should stop using int and string everywhere

From high-school through college or university, the most basic of things is learning the primitive types: int, string, byte, etc. That’s why I was astounded to learn these are frowned upon, in my transition from the academy to the industry.

In case you haven’t stepped out of the academy yet, this might seem natural for you –

public class UserAccount
    private string _name;
    private string _password;

This natural piece of code is very suitable for small assignments of no more than a few modules. However, in a larger code base, you will never see that!

How does our thought process work in that time of our life we are in college?
Is the value a number – it’s probably of type int.
Is the value a boolean – it’s probably of type bool.
Is the value a name or a sequence of characters – it’s probably of type string.

But your view of the world doesn’t work like this! In the real world, what does cross your mind when reading these:

  1. “Good morning”.

2. “l9_1x4bf4xSA”

3. “”

You think of these as 1. sentence/text 2. password 3. url. If you would ask your friend for a url, and he answer with “good morning my dear how was your trip yesterday?” you would think he lost his mind!

Basically, they are not the same at all. When you categorize them all as strings, you lose information, you allow mix-ups, you are pushing the responsibility of using them to somewhere else.

Information – while debugging someone else’s code, you find a variable of type string with the value “255-100-255”. It might be some part of an IP, a phone number, or the RGB representation of the color pink. How easier would it have been if only the variable was of type “Color”? Imagine trying to find where it was instantiated, or which part of the codes interacted with the variable in both of the scenarios.

Mix-ups – while these can be avoided with proper coding, you leave zero chance for assignments between wrong domains if you make sure they will have different types.

Responsibility – of course passwords should have some validations when created. Though, where you put these? Which file or modules are responsible for that? If your colleagues are writing a new module and they need your CheckPasswordIsStrong() function, without knowing the function exists, without communication with you, they might not know at all and end up creating their own function for the same thing!
It is much cleaner and better organized having a LoginPassword class responsible for all of the login password logic. from anywhere in the codebase it’s easy know where to navigate, and you also benefit from the power of auto-completion.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: