The Trojan

By Apoorv Tyagi

Learn to name your variables 👨‍💻

#2・ Feb 17, 2021

issues

Learn to name your variables 👨‍💻

By Apoorv Tyagi • Issue #2 • View online

🔊 If you want to listen to this newsletter as audio while you read, you can do it by clicking here (Hope you enjoy the audio version🔥🔥🔥)

Welcome to the second issue of The Trojan’s Wednesday Wisdom newsletter. I hope you all had an amazing last week.

Today I’ll be sharing some bits about naming in Software development 💻

Names are everywhere in software. Files, packages, variables functions, etc. Because naming things is one of the most common tasks that we do in software development, we have to do it well.

Also as a Software Engineer 👩‍💻, most of our time is spent reading the existing code rather than writing new one. Therefore, the code should be as readable and clear as possible.

This can be done by selecting words that are close to the human language that we naturally use. Naming is a key part of that.

Moreover, coming up with a good name reveals the nature of an entity, which helps us divide the responsibilities of our components or classes better. This ultimately leads to maintainable and extendable code.

“Programs are meant to be read by humans and only incidentally for computers to execute” — Donald Knuth

Now Grab a coffee ☕, and let’s talk about one of the important points we need to consider while naming software class / functions / variables.

Use Intent Revealing Names 💡

The name of a variable, function or class, should answer all the important questions. It should tell you why it exists, what it does, and how it is used. If it requires a comment, then the name does not reveal its intent (Exception exists 😉)

Look at the code below 👇

"bad code" example.

This code is simple, but create many questions:

What is the content of “theList”?
What is the significance of the item x[0] in the list?
Why we compare x[0] vs 4?
How would I use the returned list?

The answers to these questions are not present in that code sample, but they could have been.

We can refactor the previous code as follows to get better understanding:

"good code" example.

Now we know all the information:

“theList” represents the game Board.
x[0] represents a cell in the board and 4 represents a flagged cell.
The returned list represents the “flaggedCells”.

Notice that the simplicity of the code has not changed. It still has exactly the same number of operators and constants, with exactly the same number of nesting levels. But the code has become much more explicit.

Further, we can try to improve the code by writing a simple class for cells instead of using an array of int.

It can include an intention-revealing function (called it “isFlagged”) to hide the magic numbers.

"better code" example.

Finishing off what we left

Last week, I asked you to guess the output of the below python code I also told you that it’s not [1,8,15].

It has something to do with “Evaluation time discrepancy in python”. So Let’s find out what exactly will get printed -

(Drum roll please 🥁)

Actually,

>>> print(list(g)) will only give you one element in the list which is -

[8].

But Why?? 🤯

In a generator expression, the “in” clause is evaluated at declaration time, but the conditional clause is evaluated at run time.

So before run time, array is re-assigned to the list [2, 8, 22], and since out of 1, 8 and 15, only element that is left is ‘8’ whose count is greater than 0, the generator only yields 8.

hence, in output you’ll see - [8].

👋 That’s it for this week. I hope you liked this issue and what I included this time. Again, I’d love to hear your feedback on how I can make this newsletter better for you.

If you enjoyed this newsletter consider subscribing (in case you haven’t already) and share it with those you feel can get benefit out of it.

Have a nice week and enjoy yourselves.

👀 See you on the Internet next Wednesday!

-Apoorv;