Why transliteration in naming is a bad idea. Some interesting things about how we perceive code

Image designed by alconost.com

A surprising number of people think you can write code any way you want, and that all those rules and recommendations are merely splitting hairs. Well, everyone has a right to their own opinion.

Yet for some reason, most people refuse to read code that’s written this way.

And it’s for a good reason. Have you ever experienced reading fatigue? For example, when reading technical literature, official documents, or a foreign language? I’m sure you have. And yes, it is quite literally fatigue, albeit not the same kind as fatigue from physical exertion. Reading a complicated text places a significant drain on your mental resources.

Code is just another kind of text. And it can be written in such a way that reading it becomes a highly unpleasant, energy-sapping process. If while working with particularly horrific fragments of a corporate portal you find yourself wanting to close your editor and look at cat memes instead, the problem is probably not that you’re lazy or burned out. The problem lies with what you’re reading.

The subject of reading is a complex and extensive one. Worst of all, the internet has hardly any significant data on the topic at the level of medical research and physiology. I’m just going to touch the tip of the iceberg here, for the simple reason that to study the whole iceberg you need to have a specialized education (which I don’t have) or to conduct an equivalent extensive study of reference material (which I am not yet ready to undertake).

Let’s begin with the fact that, far from being a specific skill, the reading mechanism is, quite simple image recognition.

The brain has physiological limitations: the time required to recognize an image is nearly constant, from the moment the object meets the eye to the moment when the brain identifies the object, it takes approximately 500 milliseconds. This is not a physical constant, but a finding based on experimental data. Of course, people are different: some react more quickly than others, and even the same person may react differently under various conditions. But the average time is about the same for everyone. It is also interesting to note that image recognition time does not especially differ for objects of varying complexity: for example, a dog and the letter C will be recognized with nearly identical efficiency.

For the curious reader

After the image has been recognized, the brain adds it to its perception of the surrounding world and manipulates it in various ways. For example, we see a table, some objects lying upon it, and a room. We then generate a virtual space based on these images. Upon the table lie an apple and a knife: we know that the apple may be peeled or cut up, that it is possible to cut oneself with the knife, that the apple will roll if bumped, etc. Without taking any action we can surmise the consequences each action will have, and based on this we can conduct ourselves in such a way as to reach the desired goal.

When reading we recognize the images of letters, we correlate them with the movements of syllables (pronouncing them mentally), we construct a word based on these movements, and we include the word in our model of the textual content. This is naturally only when first learning to read; actuality, the reading mechanism is far more efficient, and the phase of pronouncing each syllable disappears altogether as we gain experience.

For example, have you ever wondered why reading speed is measured in words, not letters? The reason is simple: after reaching a certain level a person ceases to read letters and begins to read words. Reading letters is highly labor-intensive: for example, the word second would take an average of three and a half seconds to read. Instead, the brain is constantly learning, and after a certain number of encounters with the way a given word is written it begins to recognize it as a unit, circumventing the stage of constructing the word from letters.

How word recognition happens

Somewhere in our memory, master word images are stored. These being incredibly numerous, they are stored in a highly compressed state. When reading we obtain word images and compress them to the same state, then initiate a search for matches.

The search is extremely optimized. We may state with certainty that no direct sorting takes place. Naturally, it is impossible to describe this mechanism in detail, but we will attempt to create a rough model.

In the first step, words of suitable length are selected. I reiterate that the brain stores images, not textual data, and so we must understand that merely images of similar length or width are selected.

Next, the words that bear the closest outward resemblance are selected. In a manner of speaking, compressed images are held up against each other, and if the outlines of the master and the image match, they are submitted for further processing. This, incidentally, is why the brain can see words or pictures even when they are not actually there. For example, there is a well-known phenomenon of Christians seeing the face of Jesus Christ in clearly impossible places, such as the shadow of a tree or a crack in a loaf of bread.

Next comes correlation with context. Words that cannot be adjacent or that would not be present in the given text are discarded. The result is a small pool which the brain believes with relative certainty to be correct. The word from this pool that carries the most weight will be considered the correct choice.

If for some reason the pool is too large or no single word clearly predominates, the brain is obliged to go back to basics and compile it from the individual letters.

After the image has been recognized, on its basis a corresponding object is generated and entered into the virtual space of the text.

So what does this have to do with code?

For some odd reason, people write code as though they had never written or read anything in their lives. Or else as though the planet had been invaded by evil bloodsucking aliens, who were forcing them to write code at proton blaster-point.

Even in the wild nineties, the internet was not littered with the strange wRiTiNg sTyLeS u find een kod frm dvlprs of comp_softWare.

The text recognition steps listed above hardly cover every aspect of reading, but these steps have been reliably confirmed by studies and may be used to explain why certain writing habits sharply reduce the readability of a text.

The most widespread example is transliteration in function names and variables.


The master pool of a normal person has no template for the word sklads (“warehouses” in Russian). The person is forced to read it in English, vocalize it, and find an analogous word in Russian. This approximately triples the initial reading time.

An even more unpleasant example is a senseless abbreviation.

cntr_nm_code = 38;

Very likely the author wanted to say “country name code.” Hm… Perhaps. Aside from the obvious problem of reading, we are faced with the problem of fitting this object into our virtual code space. If the text contains apple, but we write apl, and then go on to specify that the apple must be cut up, we will have to write “cut apl.” When we need to write that we are assigning a country code, we intuitively begin writing “country_name_code” … and are brought up short. Our heads don’t store strings of code, remember?

After multiple uses, the brain will start to remember cntr_nm_code, but the first few times it stumbles and looks for autosuggestion.

The subject of “unsuitable” words has been studied in depth. There are studies showing that it is far more difficult to read words that are out of context or that violate proper syntax. For example, the expression “the cat’s food” is much easier and quicker to read than “the food’s cat” due to its being obviously illogical.

Nevertheless, certain developers are prone to forget about word order and even common sense when writing code.




It is a long and tedious task to go through every means of making reading more complicated. Here is a short, generalized list of the most common practices that will help you to write bad code. If you apply the above-mentioned reading model to them, the reasons will be obvious.

  • Unfamiliar words (transliteration, made-up words, obscure abbreviations)
  • Violating customary word order (activePageSet(42))
  • Word forms that do not reflect the meaning (activateTheme instead of themeIsActive)
  • Word mimicry (Name, name, _name, and _Name in a single function)
  • Arbitrary naming style order (standard PHP functions, for example)

Why all this causes fatigue

At present, there are not all that many methods of researching the processes that occur in the human brain. If scientists start poking at it with a stick, the supercomputer of the brain turns into useless biomass. In the scope of this article, I employed electroencephalographic studies.

During any activity, the brain generates electricity, and this data can be recorded. Naturally, the information content of this method may approximately be compared to attempts to study the life of a city based on infrared satellite images, but even these data are sufficient to get a general idea.

Here is an illustration from a study of human reaction to real and made-up words.

Image reposted with permission from habr.com

Similar data may be seen in this study on reading sentences with semantic violations.

As the chart shows, when reading an unfamiliar word the electrical activity of the brain nearly doubles in duration, and its potential deviates strongly from the norm. It is apparent that brain energy consumption is significantly higher, which in turn causes “fatigue” from reading these kinds of texts.

Conclusion and a bad metaphor

Though I dislike analogies, there is an excellent comparison that helps to understand what exactly we experience when reading texts with all these absurdities. Imagine that you have a screw gun. It does an excellent job of driving screws, and over the years you have amassed a wide variety of bits for every kind of fastener — slotted, crosshead, Pozidriv, TORX, hex… in a word, everything you need for ordinary work.

Then one day you find yourself needing to drive a thousand screws. You open the box and find it full of bent, rusty screws. You take out one and find that the head is slotted in the shape of a letter Z. Swearing softly, you drive it using an ordinary flathead bit, which fits with difficulty.

The next screw has to be driven with a hex bit, but only held at a 15-degree angle to the screw head. You realize that it can only be driven using a hex key. Oh, well, just this once, you think, and you drive it by hand.

The next screw is stripped. Swearing loudly by now, you drive it using pliers.

The next screw has a special magnetic lock, and can only be driven using a magnetized bit. Somewhere you find a magnet; you magnetize the bit and drive the screw.

The next screw also has a magnetic lock, but it can only be driven using a non-magnetized bit. You kick the box of screws and head for the nearest bar.

The reading mechanism is a well-oiled, finely tuned tool, which operates with fantastic efficiency. When you encounter a badly written text you are obliged to give up this tool and go back to the level at which you began in first grade. Naturally, this costs you considerably more effort, and you find yourself infuriated at being stuck doing a pointless task.

Editors note: This article has been originally published on habr.com in Russian. Translated and reposted with permission by alconost.com.

About the translator

Alconost is a global provider of localization services for apps, games, videos, and websites into 70+ languages.

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.




We localize apps, games, websites, & software and provide video production, multilingual marketing, & instant translation services. Visit us at alconost.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Meepwn CTF Quals 2018 Writeup — Part 1

Microsoft Announcing ASP.NET Core in .NET 5 | What’s new in .NET 5?

5 Levels of Using Sets in Python

5 Levels of Using Sets in Python

Striver Sheet Day 07 — Linked Lists and Arrays

Bikeshedding my dev env

Why it is worth choosing Shopware? Implementations review

The Six Most Important Things to Know About Python Functions

Leetcode Q231. Power of Two (Q223)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Blog of Alconost Inc.

Blog of Alconost Inc.

We localize apps, games, websites, & software and provide video production, multilingual marketing, & instant translation services. Visit us at alconost.com

More from Medium

My first week at Everest Engineering

How we develop a software in GoGoSoon

I worked myself out of a tech job not once… but twice

A Developer Spills His Secrets: 4 Tech Stacks for (Almost) All Tech Product Use Cases