Language is all about nouns
When humans talk about things, we always talk about specific nouns. Nouns have names. We may not know the name, but there is a name.
When you go on a trip, and you need to pack your clothes. You go to a shop and buy a suitcase. You know it is a suitcase. You don’t go there and ask for “the thing you use to transport clothes.” If you did that you would probably end up with a cardboard box. Imagine checking-in a cardboard box at an airport.
Unfortunately, programmers are afraid of nouns.We tend to use descriptions instead of names.
Picture this situation in your mind. You sit in front of your computer, and you need to write some code which sends a marketing newsletter to your customer. What do you see? Is this an EmailAddress type or a String called “emailAddress”? How do you know it is the email address? You have a validator, you can call it. Great. How do you know the person wants to receive the email? You store verified email addresses and all the newsletter subscriptions in your database.
Not only you don’t have a noun. You have just a description and some assumptions you must verify every time you want to use it.
Do you want to show your product/service to 25000 data science enthusiasts every month? I am looking for companies which would like to become a partner of this blog.
Are you interested? Is your employer interested? Here are the details of the offer.
Why don’t you call the customer’s email address a MarketingNewsletterRecipientAddress? Too long? Do you want to know what is too long? Your code.
You have to check whether the email address has been verified. You have to check whether the person wants to receive this type of newsletter. You did it once. Maybe you wrote a database query which returns only such recipients.
Can you trust it? What if someone modified the code, and you don’t even know it? You end up with a lot of repetitive code just to check all the preconditions. A lot of defensive programming.
If you encode your assumptions in the type, the code gets self-documenting. You look at the class name and instantly know everything you need. What else? During meetings with the business, you talk about things which exist in the code. You don’t need to translate the requirements from human language to “programmer speech.”
You don’t need to strip nouns from their meaning and replace it with poorly written descriptions. Yes! Those descriptions are poorly written. You have a generic type (a String, an Integer), some name that hopefully tells you something about the role of the variable, and assumptions scattered around in many places.
Don’t try to be clever. Just call it what it really is.
Remember to share on social media! If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.