Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 Below are the most common mistakes programmers make when naming variables and functions in their code. These examples are taken from the projects of Hexlet students. I use JavaScript for demonstration purposes only because it is the most universal language, so the examples have nothing to do with the language being used. These mistakes are found everywhere in equal proportions.

2 Materials underlying naming conventions:

3 <ul><li><a>Code complete: Naming in programming</a></li>

4 </ul>Long story short.

5 It is perfect if the name alone is enough to understand what the variable stands for or what the function does, rather than how it does. If you have to study the code around that name to get an understanding, it's probably a bad name. The message here is: Don't bother me when reading your code!

6 <h3>File?</h3>

7 My "favorite" variable name is file. It's even more "wonderful" when you can't see the moment it was assigned (for example, when you pass this file into a function):

8 What is a file? Asking this question to different people will provide different answers. Regular ones are as follows:

9 <ul><li>File contents</li>

10 <li>Filename</li>

11 <li>Path of a file</li>

12 <li>File descriptor</li>

13 </ul>All of these variants actually exist. However, the latter is more common in C languages, where a file is indeed a file descriptor.

14 Fileis a bad name; it forces conversion from its name to its real meaning: "call it a file, mean a path" or "call it a file, mean a content". The proper names arefilepath, filename, content.

15 <h3>Hungarian Notation</h3>

16 The Hungarian Notation is an identifier (variable and function) naming convention, which comes down to encoding the data types directly in its name: e.g.userArray. This naming is about fighting the consequence rather than tackling its cause (bad names). Let's review some typical examples.

17 <ul><li>Arrays. Dealing with an array means we deal with a collection of some elements with names. The perfect name for such an array is the name of that element in plural:users, cars, numbers, or, at most,items. It clearly shows that we are working with a collection.</li>

18 <li>Strings. Quite simple: if we are working with an arbitrary string, we can name ittextorsentence. For more specific cases it can becharorword.</li>

19 <li>Numbers. It's even easier:numberis anumberanyway. However, a name that fits the purpose of the number is certainly better: e.g.denom(denominator).</li>

20 </ul><h3>Common names</h3>

21 Projects often have such names asbeforeandafter(ornewandold). It immediately raises the question:what before?What after? No idea what we are talking about without knowing the code. Those situations I was referring to meant the value before the change and the value after the change. In fact, it's all about naming variables to reflect this essence:valueBeforeandvalueAfter.

22 The same goes for functions. What do you think happens in the code below?

23 There is no chance to guess that. There may be situations with such code being appropriate, but they are few and far between. A function must tell you what it will result in, not what it does.

24 <h3>Function as a noun</h3>

25 Naming functions with nouns is an antipattern, even among experienced developers. Below are examples, where the left is how it is written and the right is how it should be according to the meaning:

26 <ul><li>diff(value) => genDiff(value)</li>

27 <li>parser(data) => parse(data)</li>

28 <li>value(user) => getValue(user)</li>

29 </ul>There are relatively few commonly used words to describe different actions in programming. These include modal verbs and words likerender, build, generate, show, enable, set, get, edit, and others.

30 This also includes mixed-up word order. Sometimes we see these versions:diffBuild, while the opposite is correct:buildDiff. First, what we do (what action), then on what (the subject the action is aimed at).

31 <h3>Abbreviations</h3>

32 It is normal to use abbreviations in programming. Words can be long and awkward, so some abbreviations are nearly commonplace. For example, namingnumberasnumis quite usual. But sometimes you can come across rather interesting variants. I've seen these:

33 <ul><li>empt(short for empty)</li>

34 <li>hid(short for hide)</li>

35 </ul>This abbreviation not only doesn't make it better, it makes it worse, since the full word is no longer obvious, and it can be difficult to read the name. I don't know why you would cut one letter short, but it's definitely a bad idea.

36 Long names, on the other hand, are usually a good choice. Don't be afraid of them. For example, Rails has functions with the following names:distance_of_time_in_wordsoroption_groups_from_collection_for_select.

37 <h3>Paired vs unpaired</h3>

38 There are often cases in programming that are perfectly suited to antonyms (words that have opposite meanings). For example, start-end, new-old, before-after. You should know how to choose these words properly. What is an antonym forbegin, for example? The right answer isend, notfinish(an antonym for start), as many people think.

39 I constantly see pieces of code where one word is made correct, while the other remains neutral. Typical example: we have an old value and a new value. The programmer creates a pair ofvalueandnewValue. However, this is not correct. The issue is that this pairing doesn't make the connection obvious. Moreover, we should be lucky enough to guess thatvaluemeansoldValue. And as you remember, a name should immediately tell you its meaning and you should not have to guess.

40 <blockquote><h3>Additional materials</h3>

41 <ul><li><a>Code complete: Naming in programming</a></li>

42 </ul></blockquote>