Lesson 18 - Most common mistakes of JS beginners - Naming variables
Word of senior programmer
I compiled the material for today's lesson based on 20 years of programming experience. As an editor-in-chief and a lecturer, hundreds, maybe thousands of source codes created by the community have passed through my hands. It was not difficult to notice that most of them, although working, contain unnecessary errors, which are also repeated over and over again. Surprisingly, mistakes were often made by both novice and more experienced programmers, and I made them when I started as well.
I have come to the conclusion that the basic and false assumption is:
✗ The program is correct if it works.
Programs and houses
If we build a house that we love and the wind doesn't blow inside, it doesn't mean it's flawless. The house must have a well-thought-out architecture, and if it has no foundations, it will start to collapse in a few years.
Programming is often compared to a construction in terms of architecture, but here, we mean software architecture. Let's explain why.
The human brain can only work with a limited amount of information at a time. Simply put, if a program is cluttered, from a certain point on, the programmer would have to keep more things in mind than one can. Adding additional functions to such a program will always cause an error in the application. In real life, it turns out that the author of a hobby project "stops having fun" or the commercial project goes bankrupt because it is "already too complicated".
Let's take another example - If our household was arranged so that we had a hammer in a first-aid kit which will be placed in the basement, it would probably be difficult for us to function effectively in this kind of household. Although this example sounds absurd, its program alternatives are emerging daily.
When is the program correct?
It is easy. The program is correct if it:
- adheres to good practices and
- is tested.
Note that the functionality from the program user's point of view represents only 1/3 of the program's quality criteria. Like the functionality of the house from the point of view of the occupant, it represents only a fraction of its real quality in terms of construction.
We will be talking about breaking "good practices" and the quality of the code today. We care about you being excellent, so you will find a few more of these lessons across our courses.
How to name variables correctly?
It is said that 10% of the time we program something and 90% of the time we come up with a name for it;-) This is, of course, an exaggeration, but the joke comes across the need to spend some time figuring out the names of the variables. That everyone, including us, who returns to our own code after a few months, understands what the variable is for. In general, you can rely on a simple rule:
We always name variables according to what they contain, not according to what they are used for in the program.
Let's compare the following 2 codes:
let list, text2; let array; let foo, bar, x, calculation;
let title, name; let answers; let i, j, bonus, totalBonus;
Both codes create variables for a simple quiz. In the first example, it is
not at all clear what some variables contain, e.g. naming a variable
array has about the same meaning as if we would call it a
A common mistake is that we want to save the result of a
calculation, for example, and name the variable
calculation. However, the calculation is not related to the
variable at all, it is an action, the variable always contains
a value (the result of the action). This is the case with the
totalBonus in the quiz. Similarly, in the first code named variable
list because it is being listed somewhere. But we can really see
from the second code that it contains the name of the quiz.
Hand on heart - would you understand that the code on the left is a quiz program?
We also never name the variables
Pay attention to "Czechglish" and diacritics
In the source code, at our beginner level, it does not matter in which language we will name the variables (unless we send the code in Czech to an Englishman).
We name variables in one project in one language and, if in Czech, without diacritics!
Let's show some examples again:
let zprava = "Hi!"; let count;
let message = "Hi!"; let count;
let message = "Ahoj!"; let count;
We never use hooks and commas in identifiers (e.g. variable names). Of course, this is already fine in the values stored in them.
Although modern languages support UTF-8 encoding in identifiers, it is very easy to forget a hook or comma and then use another variable ! In addition, the source code file can be processed by an application that does not support it, and this typically happens over time (for example, it is sometimes a problem to display accents in an attachment by a mail client, etc.).
Today's applications are increasingly complex. It often happens that one word
is not enough to describe what is stored inside a variable. Then it is
advantageous to use more words. Short identifiers from the 1980s thus alternate
with relatively long names such as
and the like in current business applications.
However, such a long name only makes sense in a complex
application, where there are several similar variables, so we have to add
another word. So in the Hello world application we will not create the variable
textWithAHelloWorldGreeting, but we only need a
greeting there, if there is no other:)
For the readability, we must somehow separate the words in such a variable name:
- We separate several words according to the convention of the given
camelCase(where every other word has a capital letter and the name then looks like camel humps). In other languages, for example, an underscore such as
snake_caseand other notations can be used.
- If possible, we avoid numbering variables and do not write numbers in words
at all, not
greetingTwo. "Two" says nothing about what the greeting contains.
Let's look at examples:
let message1; let messageTwo;
It is not clear here what is stored:
let received; // text, bytes, message, order, ...? let sent;
And here is the name illegible:
let receivedmessage; let sentmessage;
let receivedMessage; let sentMessage;
We do not use abbreviations
Let's start this subchapter with the quote:
Everyone was wondering what was the columnThis bad practice is actually the opposite of multi-word variable names. We do not come up with nonsensical abbreviations, for example, no one knows
DATBIRfor. Once it was discovered that it was the date of birth.
receivedMessage. The aid can be:
If someone other than us looks at the code, they should know exactly what is in the variable.
let ms; let mc;
let message; let messageCount;
As promised, we will return to the topic of good practices several more times in similar, rather relaxing lessons:)
No one has commented yet - be the first!