Conventions: Semantic Programming

It’s been a while since I’ve covered a form of programming conventions, and considering I’m fresh off a holiday, it’ll be a simple but important topic this week: Semantics.

Merriam-Webster Dictionary defines this as “the study of meaning”. If you’re learning a new language, such as Spanish or French, you may come across a word you haven’t seen before like queso or fromage. When you rack your brain to try to decide what that word means, you’re looking at the semantics of that word only to discover it’s the word for cheese.

Why is this important?

It’s important because text on a screen or a page don’t have all of the aspects of a conversation. There’s no added in voice tone or body language to read, and can easily be misreading. I’m sure anyone reading this can somewhat relate this to deciphering text message conversations.

Have you ever been texting a close friend or someone of romantic interest and you try to decipher every single message like it has some deeper meaning? Well, sometimes it does. The way you type and send messages can either intentionally or accidentally convey emotions. Imagine you’ve just sent a text to someone asking how their day was, and their entire response was just “Ok.” I’d imagine you would probably think something is wrong: this person had a rough day, maybe I did something to aggravate them, they may not be in a talking mood, etc. All of these thoughts could have crossed your mind and at the end of the day, it could be none of the above. That person could straight up be a lazy texter. However, the very reason any or all of these thoughts whipped through your head was due to the semantics behind the text as a whole. Past experiences with people who you have had wonderful conversations will lead you to believe that the response you received was unnatural. It was short, blunt, and lazily typed. It probably took less than five seconds to type and press send.

Now let’s attack this from a different angle. If you’re reading this article, that means you’ve read a book sometime in your life. Hopefully you’ve read a book or two that you’ve enjoyed, and you’ve most definitely read at least one book that you did not enjoy whatsoever. There could be many different reasons for this, but majority of the time it comes down to the fact that the story was just uninteresting. Hey, you may even be bored reading this article, and it has a lot to do with semantics. Let’s look at some different sentences:

Bobby traveled to the local Best Buy, hoping he’d locate the new PlayStation.

Bobby raced to the local Best Buy, hoping he’d track down the new PlayStation.

Bobby walked to the local Best Buy, hoping he’d come across the new PlayStation.

All of these sentences convey the same base meaning: A man is looking for a piece of hardware. However, modifying the verb usage changes the details. In the first sentence, it sounds like Bobby is on a cross-country mission to find the rare new console. In the next one, Bobby hopped in his car and committed multiple traffic infractions trying to get his hands on the new console. And in the final sentence, it sounds like Bobby is taking his time and enjoying the trip, with the console as a side thought. All of the different meanings derived from switching up the verbs is thanks to semantics.

Nice tangent, how does this relate to programming?

It helps with readability! At some point or another in a programmer’s life, someone else is going to read your code. It’s quite literally unavoidable. At any point in the time where you are learning to write code to trying to land your first job as an engineer, your code will be reviewed by another human being, so you always want to try to make it as easily digestible and as semantically sound as you possibly can.

In the same vein that it’s important for a novel write to user descriptive nouns and verbs, it’s essential for programmers to do the same with variable and function/method naming. Apart from some specific keywords reserved by languages such as return, the names of arguments and variables in your methods are completely up to you, so it’s important to try to choose names based on the context of your codebase. The importance of these decisions greatly expands with the size of the codebase. Larger codebases have more ins and outs, so it’s helpful to the author and the reader to have descriptive names. Some important aspects to consider:

• What section of code am I writing in?
• What resource does this section of code refer to?
• What kind of task does my function perform?

For example, if you are working with arrays and objects, instead of naming everything arr or array, you would probably at the very least tack on the name of the resource it’s affiliated with, such as animalsArr or astronautsArray. Doing so will make it easier for whoever reads the code to decipher how everything connects and what all the moving parts are trying to accomplish.

Conclusion

Don’t be lazy! Respond to your friends with meaningful words. Write stories with descriptive word usage. Build a codebase that displays its functionality and relationships to the rest of the code. That’s all for this week, thanks for reading and happy coding!