Primitive Obsession – The code smell

Programming languages divide their types mainly into two categories.

  • Primitive types (A built-in types like string, boolean, int, decimal…)
  • Objects (class/function): User-defined types using class-based/prototype-based objects.

A primitive data type is a data type for which the programming language provides built-in support. Example: number, string, boolean, date and so on.

There are situations when developers should represent their idea/concept using user-defined types (Abstraction or encapsulation).

Whereas they choose to use primitive types (inbuilt int, string…) to represents the concept.

“Talk is cheap. Show me the code.” ― Linus Torvalds

Consider the above API for scheduling meetup.

If you observe carefully, all the parameters: topic, description, date, location id, and max participants when they stand together represent the concept/idea called meetup.

Almost all the data types are primitive types (Built-in types: string, int, DateTime and so on).


Overutilization of these primitive types to solve a problem makes the code more verbose/procedural and logic to deal with them is scattered.


Since all method parameter stands together to represent the concept called Meetup.

Here, we could group all these parameters together to represent the idea/concept called meetup. So, introduce an object to gather these data values.

Upon replacing data values with an object API would look like:

This is how the API should have been. However, the developer chooses to go with all built-in types (segregated). IMO, this overutilization of primitive types in almost all cases can be treated as an obsession about primitives which can be called a primitive obsession.

I have explained only one scenario and there are other scenarios too.

Don’t use abbreviations while naming variables

In the month of February 2018, technogise had conducted the code retreat session for engineering graduates. I was one of the facilitators for the activity.

We asked students to solve problem statement. It was about calculating the final price of product item when it’s price per item, quantity and tax slab for category (Product item belongs to category) was given.

When I went through the code for some of the students, it led me to write this post.

Please read the code below. Some of the students had written code something like this.

Note: Please use laptop or desktop to view this code for a better experience.

Were you able to understand the code? After few minutes of repeated reading, you could.

It’s difficult to know the meaning of the variables like CGR, iCat, iName, iQnt, cPercentage, fPrice and so on?

It creates complicated mapping in your brain. You need to scroll up and down to understand the intention of everything, isn’t it?

Now let’s see same code after giving little better names.

Do you see how simple it becomes as soon as you write meaningful names?itemName, itemQuantity, ratePerUnitItem, gstPercentageForItem, finalPrice and so on. Now the variables are conveying their intent, better than the first snippet? (I agree, I could use better data structure or use LINQ. However, I am simulating the what students had done. They used different programming languages. This code is for demo purpose.)

Now, you don’t need to scroll up and down to understand the intention of the variables. This is an impact of giving meaningful names to variables.

Don’t use abbreviations for variable names

Hence, we should spend little more time on giving the meaningful name to the variables (Same thing is applicable to the class, namespace, methods, and so on ) so that when you or maintenance developer revisits your code to fix a bug or add a feature, she/he could do it very easily. It should be flawless. Consider the situation when using abbreviations while giving names to variables throughout the project. It would be a nightmare to maintain such a code.

In next blog, I will use this example to convey more techniques like “extract method”.