
Pybites Podcast
The Pybites Podcast is a podcast about Python Development, Career and Mindset skills.
Hosted by the Co-Founders, Bob Belderbos and Julian Sequeira, this podcast is for anyone interested in Python and looking for tips, tricks and concepts related to Career + Mindset.
For more information on Pybites, visit us at https://pybit.es and connect with us on LinkedIn:
Julian: https://www.linkedin.com/in/juliansequeira/
Bob: https://www.linkedin.com/in/bbelderbos/
Pybites Podcast
#086 - Code == communication, on writing better variable names
Naming things is hard! Hence in this episode we want to help you a bit with that and share 10 tips how to do this better so you will write more readable and meaningful variable names. Enjoy!
Check out mentioned Pybites Developer Mindset program here. Having you build apps end-to-end and getting expert developer code reviews has been an eye-opener for people, invaluable. Apply right there if interested.
Take that extra bit of time to really think what you try to express. Code equals communication. Your team and even your future self will thank you because it reduces cognitive load and probably the WTF per minute rate. Hello and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. A couple of weeks ago we sent an email out code communication ten tips on making your code more readable, and we thought it was actually so important because naming things is really hard. So yeah, let's dedicate a podcast episode to those ten tips and hope they help you when you review your code. When you write your code to name things more intuitively and lessen the cognitive overload that can typically happen with code. So here we go. In programming, naming things matters. When reading a call to a method with a vague name, you will need to spend some time upfront to understand what the method does, and it will likely take several exposures before the functionality of the method is stored in your LTM or long term memory, and that comes from the programmer's brain. By Fellin Hermans the bad news naming things is hard. The good news? It's learnable, and you can develop the habit with practice and over time. Here are ten tips for better variable names. One, avoid single letter variables. They dont express intent. Besides, they clash with debugger commands. An exception would be loop counters as produced with enumerate. For example, for those I tend to use I not a pdv command, by the way, although in the context of looping through a file line, number is still more readable. Two, be specific around purpose. Explicit is better than implicit from the Zen of python. For example, if you have a variable called data, bad variable name does not say anything. Okay, so then we have temperature. Okay, now I know at least what kind of data it is, but you can also put a little bit more effort into it and call it temperature in underscore celsius. That's even better, because not only do I know that it's temperature data, I also know the unit Celsius. Right? The data is more specific and therefore more readable. Three, longer variable names are okay. You have more space to express meaning, and the variable names become more unique, hence better searchable, especially when your codebase grows. However, don't go overboard with the length. My constants tend to be the longest, relatively speaking. Four, don't put types in your variable names, also known as hungarian notation. You can use typeins since Python 3.5, and we encourage you to do so. By the way, listen back to episode 82 with Bill Frey and you can learn all about type hints. Five, apart from typing, you can hint at what type of variable it is by certain prefix. For example, for boolean variables or function methods for that matter, you can use is or has. For example, is admin is valid, has access has replied. Your brain is quick in processing that these return true or false. Again, readable variable names code is all about speeding up your understanding of the code. Six, use more variable names or group them together. For example, if you refer to variables by indexing user settings index zero, user settings index one, etcetera, why not use tuple unpacking to get more meaningful intermediate variable names, for example? So here's an equation, right? So on the left side we have first underscore name, last name, age, profession separated by commas equals user settings. So we're unpacking user settings that has four elements and we put them into four intermediate variable names that are better named and hence easier to reason about. So you avoid the indexing altogether. And another way I often do this is to group variables together into an object, most notably a data class or name tuple, and then you can access the variables as attributes. So in this case, where we had a list of user settings, you can actually have an object called user and access the attributes like user first name, user last name, user age, user profession, and that's super readable. Seven, in Python, use a single underscore to mark a variable as internal. And that's in air quotes, because there's nothing really internal in Python. Python lets you override anything, but the underscore is a message to other developers like hey, this variable is only used in this namespace. So again, Python does not enforce it, but it's a way of communicating to fellow developers. I also use a trailing underscore times to disambiguate built in functions because you never want to overwrite those, for example, max min underscore. However, usually this means I'm lazy and I can put a bit more effort into choosing a more meaningful variable name. So, for example, if I would do sum underscore to not clash with the sum built in, why not call it total? Or even better, total underscore score. That sounded funny. Total underscore score. This definitely is probably better written. Eight. Similarly, if a variable is not meant to change, you should make it a constant. And as per pep eight in python that means making it snake case, but all uppercase. This is especially important in the context of magic numbers. For example, if you have ten, the integer ten somewhere in your code as a lower boundary, a fellow developer does not know that you mean lower boundary. It's more readable putting that into a constant and place it at the top of the module. For example, min score or min score four underscore ninja belt again, my constants are relatively long but more readable, and those variables are all uppercase. And here are some other examples we use on the platform. Num bytes four underscore ninja sert 100 min upvotes four underscore ranking equals ten, PDM duration equals 84, and actually it would even be better to do PDM duration underscore in underscore days. You get the point. Another example is complex regular expressions. Looking up those constants, I spotted this regular expression that might be hard to read. I'm not going to read out the whole thing, it would be horrendous. But basically it had a few sub expressions to match eight non space characters. We use it to validate a license key, but that was not immediately obvious. So you can easily put your regular expression in a read compile and assign that to a constant, for example, valid license key. Again, use the opportunity to define more names in your program and your code will be exponentially more readable. Nine. I prefer to write all my code in English, as it's the lingua franca between programmers. I I also wouldn't use special characters, for example Tilde or the typical characters in Spanish. No, I just keep in plain English without special characters to avoid any encoding issues. And lastly, number ten, follow your style guide. So for Python that means pep eight, which has clear rules for naming. Alright, that's it. Ten tips for more readable code because again, code is all about communication. I hope these tips are useful. Take that extra bit of time to really think what you try to express. Code equals communication. Your team and even your future self will thank you because it reduces cognitive load and probably the WTF per minute rate. Now go put this into practice and make your code more readable. And if you're struggling with this, just take notice of PDM or Pyweight Developer mindset program we have you build two apps end to end, and through that process there will be dozens of code reviews where our experienced mentoring team will guide you and teach you how to write more quality code. So if you want to know more about that. The link is below in the show notes. Hope this is helpful and we will be back soon with a fresh new episode. If you like this format of adding more technical topics to our podcast as opposed to Julian the mindset, then please let us know and we happily incorporate that. Thanks for listening as always, and see you in the next episode. We hope you enjoyed this episode. To hear more from us, go to Pibyte friends, that is Pibit es friends and receive a free gift just for being a friend of the show and to join our thriving slack community of python programmers. Go to Pibytes community, that's Pibit es forward slash community. We hope to see you there and catch you in the next episode.