We already know how to work with variables in Python. But it's not enough to know how to use them. Also, appropriate naming of variables is necessary so people can read them correctly.
Imagine we've set the following program:
x = 'Father!'
print(x)
We've worked with a similar program before. The only difference is that the variable name has changed to x.
The computer doesn't care what we call a variable. Names are only essential to people. Programmers usually read other people's code much more often than they write it. We should name our variables to make it easy for our colleagues to read and analyze our code.
It's crucial to choose an explicit naming that reflects the idea of the variable. It's important to give names that are understandable without context and without examining the surrounding code.
There is one generally accepted rule, only use English names. If you have difficulty with English, use a translator. Over time, by poking around in other people's code, you'll learn how to name variables appropriately.
There's a joke among developers that naming variables is one of the hardest things in programming. It's hard to come up with names. For example, it's difficult to name a variable that stores the number of unpaid orders from customers in arrears in the previous quarter.
Try this task to test yourself:
Think of a name for the variable that will store the «number of siblings of the king».
Write it down in a notebook or email it to yourself. Don't put anything in there except the name of the variable. And in a few lessons, we'll come back to this topic.
Now let's look at how to find simple and understandable variable names.
Variable naming
We begin with greeting, an example of a simple name. But not all of them are that simple. Often they include several words: for example, client name. Different languages have different naming styles for variables.
There are three main variable naming conventions, which are sometimes combined. These conventions apply to variable names consisting of several words:
- kebab-case — the constituent parts of the variable separated by a hyphen (
my-super-var) - snake_case — underscore (
my_super_var) is used to separate words - CamelCase — each word in the variable is capitalized(
MySuperVar)
Python programmers name variables in the snake_case style: words are written in lowercase letters and separated by the underscore character _. To find out more, you can study the section «How to name variables» in the PEP8 standard.
Next, we will look at an example of bad practices and consider why we should avoid them.
Magic numbers
Let's look at our example of the program that calculates exchange rates:
euros_count = 1000
dollars_count = euros_count * 1.25 # 1250.0
rubles_count = dollars_count * 60 # 75000.0
print(rubles_count)
From professional development's perspective, this code doesn't correspond with the best practices.
In this example, it is difficult to understand what the numbers 60 and 1.25 mean. Imagine you will deal with that code a month or a year from now – it will be difficult. It'll also be difficult for a programmer who hasn't seen the code before.
The context of our example is easy to put together because the variables are named correctly. But in real projects, code is much more complicated, so it's often impossible to guess the meaning of the numbers.
The problem lies in magic numbers. These are numbers whose origin is impossible to understand at a glance – you have to dig deep into what goes on in the code.
To prevent this problem, you need to create variables with the correct names. That way, everything will fall into place:
dollars_per_euro = 1.25
rubles_per_dollar = 60
euros_count = 1000
dollars_count = euros_count * dollars_per_euro # 1250.0
rubles_count = dollars_count * rubles_per_dollar # 75000.0
print(rubles_count)
In this program we:
- Use the name in snake_case
- Separate the two new variables from the following calculations using a blank line. This separation is appropriate because it increases readability because these variables make sense without calculations
- Write the well-named and structured code. It is longer than the previous version. It is often the case, but this is fine because the code must be readable
Magic numbers and obscure variable names don't break the code, but they do make it less readable.
It is important to understand that the computer will carry out the calculation you give it anyway. However, another programmer reading the code won't understand, thus complicating your work.
