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.
We asked them to write a program which calculates the final price of product items in a shopping cart, when the initial price of each item, the category in which each item falls, their quantity and the GST (goods & services tax) slab applicable to each category was given.
Going through the code for some of the students led me to write this post.
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 a better data structure or use LINQ. However, I am simulating what students had written. They used different programming languages too. 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 meaningful names to 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. Avoid using abbreviations while giving names to variables throughout the project. It would be a nightmare to maintain such code.