I personally find reading code full of Unicode identifiers confusing. In my opinion, it also prevents the code from being easily maintained. Not to mention all the effort required for authors of various translators to implement such support. I also constantly notice the lack (or the presence) of Unicode identifiers support in the lists of (dis)advantages of various language implementations (like it really matters). I don't get it: why so much attention?

  • 1
    Do you mean names for things, or do you mean special characters like stars, lambdas and middle dots? Commented Nov 14, 2011 at 8:11
  • 7
    lol ! Did you know that a world exists outside english speaking contries ? Amazign discovery, isn't it ?
    – deadalnix
    Commented Nov 21, 2011 at 11:00
  • 4
    deadalnix: I live in such a country, so we might use identifiers like größe. That said, I never do that and I strongly discourage doing that. Therefore, the quesition is very valid.
    – user281377
    Commented Nov 21, 2011 at 14:35
  • 2
    deadalnix: I've never been in an English speaking country so far. Why not paying attention to the actual question, not the questioner? Commented Dec 17, 2011 at 19:47
  • 6
    I wish languages would focus on getting Unicode right in string handling and leave out the fancy unicode identifiers. Good programming resources are in English anyway (StackOverflow), so let's admit programming should be done in English (also makes sharing easier) and focus on implementing proper Unicode string manipulation. Commented Jan 1, 2012 at 13:23

8 Answers 8


When you think unicode, you think Chinese or Russian characters, which makes you think of some source code written in Russian you've seen on the internet, and which was unusable (unless you know Russian).

But if unicode can be used in a wrong way, it doesn't mean it's bad by itself in source code.

When writing code for a specific field, with unicode, you can shorten your code and make it more readable. Instead of:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

you can write:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

which may not be easy to read for an average developer, but is still easy to read for a person who uses mathematical symbols daily.

Or, when doing an application related to SLR photography, instead of:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

you can replace the aperture by it's symbol ƒ, with a writing closer to ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

This may be inconvenient: when typing general C# code, I would prefer writing:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

rather than:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

because in the first case, IntelliSense helps me to write the whole code nearly without typing and especially without using my mouse, while in the second case, I have no idea where to find those symbols and would be forced to rely on the mouse to go and search them in the auto-completion list.

This being said, it's still useful in some cases. currentLens.GetMaximumƒ(); of my previous example can rely on IntelliSense and is as easy to type as GetMaximumAperture, being shorter and more readable. Also, for specific domains with lots of symbols, keyboard shortcuts may help typing the symbols quicker than their literal equivalents in source code.

The same, by the way, applies to comments. No one wants to read code full of comments in Chinese (unless you know well Chinese yourself). But in some programming languages, unicode symbols can still be useful. One example is footnotes¹.

¹ I certainly wouldn't enjoy footnotes in C# code where there is a strict set of style rules of how to write comments. In PHP on the other hand, if there are lots of things to explain, but those things are not very important, why not putting them at the bottom of the file, and create a footnote in the PHPDoc of the method?

  • ASCII includes 37 characters that can be used in identifiers; I would expect that in most fonts, they are sufficiently visually distinct that even people not fluent in the Latin alphabet could learn to tell two strings of characters in different fonts were the same identifier. How much debugging effort is going to get wasted when a programmer uses "Ф" for an angle instead of "Φ"?
    – supercat
    Commented Apr 10, 2014 at 20:11
  • 1
    @supercat: good point. But the example you give shows a bad use of a tool rather than that the tool itself is bad. Δx or -∞ are valid uses (with some drawbacks I explained in my answer). Ф/Φ on the other hand are just signs that the programmer doesn't understand how to name variables properly. Commented Apr 11, 2014 at 6:31
  • 1
    If a programmer was wanting a lowercase Greek letter theta (e.g. for a horizontal angle), do you know which of the symbols I gave is the right one? There are lots of groups of characters which look very similar if not identical. If source files were required to contain directives specifying what characters could coexist within identifiers that might help, but otherwise I see lots of potential confusion between variables named accurately with foreign characters versus those named with look-alike characters.
    – supercat
    Commented Apr 15, 2014 at 12:59
  • 1
    @supercat: you meant Greek letter phi? My point is that if the programmer uses this symbol in an application where the term of "cumulative distribution function" is expected, any person aware of the domain terminology and symbols will understand what Φ means. cumulativeDistributionFunction is too long. CDF is less readable than Φ. cumDistFunc is ugly. This also means that if the programmer uses the Cyrillic small letter EF (Ф) instead in this context, it's simply a mistake. In the same way, a programmer could have used a wrong term or a wrong abbreviation. Commented Apr 15, 2014 at 16:40
  • 2
    If a variable name is composed of underscires, 0-9, a-z, and A-Z, someone with a copy of the code that doesn't support copy/paste (e.g. a printout) may reasonably hope to reproduce it accurately. Someone trying to copy "ɸ" without knowing what it means might very easily end up with "Ф", and even if the programmer knows it's supposed to be "phi" it wouldn't be obvious whether "φ" or "ɸ" is appropriate. [One is "Latin Small Letter Phi", and one is "Greek Small Latter Phi"--they appear clearly distinct in this comment font, but not in e.g. Lucida Sans Unicode].
    – supercat
    Commented Apr 15, 2014 at 16:55

I would say:

  1. to ease non-professionals and novices that learn programming (e.g. at school) and don't know English. They don't write production code anyway. I've seen many times code like:

    double upsos, baros;
    cin >> upsos >> baros;

    Just let the poor guy to write it in his language:

    double ύψος, βάρος;
    cin >> ύψος >> βάρος;
  2. Don't you like it?

    class ☎ {
        ☎(const char*);
        void 📞();
        void 🎧(👨);
    ☎ ☏("031415926");
    ofstream f;
  • Ironically, the code under "Dont' you like it" doesn't render properly, which kind of illustrates the point of why you might want to stay away from using funky characters.
    – Kris
    Commented Apr 9, 2017 at 17:25

As far as I am concerned, this is purely for marketing reasons. And additionally may make our lives harder.

The marketing arguments

You know this crazy lists of features that most languages boast off ? It's pretty much useless in general, because it's so far from the language that it does not provide much information on specific, but it does allow one to quickly dress tables with ticks and crosses and rightfully conclude that since X has more ticks than Y it must be better.

Well, Unicode support for the identifiers is one of those lines. It does not matter that compared to Lambda support, Generic programming support, etc... it might not be much, people drawing the tables don't care about the quality of each line, only about the number of them.

And thus they can boast: "Ah, with Y you do not have Unicode support for your identifiers! In X we do, so for students it's much easier!"

The fallacy of accessibility

Unfortunately, the argument of accessibility is fallacious.

Oh, I do understand that being able to write "résultatDuJetDeDé" instead of "diceThrowResult" (yes I am French) might seem like a win in the short term... however there are drawbacks!

Programming is about communicating

Your program is not only meant for the compiler (which could care less about the identifiers you use), it is also meant for your fellows. They need to be able to read it, and understand it.

  • reading it implies being able to visualize the characters you used, Unicode is not so well supported by all fonts
  • understanding it do mean relying on identifiers -- unless you supplement them with lenghty comments, but that is violating the DRY rule.

Of course, your classmate may speak the same language you do (not obvious, I had programming classes with Germans, Spanishs, Libanes and Chineses), and so may your teacher... but suppose that somehow you are working on it at home and suddenly need help: Internet is great, you may speak to thousands of thousands of people that know the solution, they will only answer if they understand your question though. And you need to understand their answer as well.

Programming requires understanding

Accessibility and initiation require basing yourself on libraries to do the heavylifting for you: you don't want to reinvent an IO layer to read from/write to the console on your first assignment.

  • In which language are those libraries written ?
  • In which language are those libraries documented ?

If you answer Morrocan Arabic, I will be surprised.

Unless you only rely on the lectures you assist to, and those present comprehensive documentation on every library feature you will need to use (and perhaps even translated libraries), then you will have to learn a modicrum of the English language. But then, you probably did already long before you started this programming course anyway.

English is...

... the lingua franca of programmers (and most scientists).

The sooner one admits it, and goes along with it rather than fighting against it, the sooner one can truly learn and progress.

Some will inevitably raise against this, and rightly defend their right to speak the language of their choice (their maternal language usually), however, as Babel demonstrated, the more languages are used, the more difficult communication gets.


Yes, as it had been argued over and over, some Unicode support (mainly symbols) can greatly ease comprehension for people having to translate mathematical or physics formulas, for example, into code. There is the drawback that some symbols are overloaded, but it could still help.

So why ?

Well, as said, it's not really about user convenience, as much as it is about marketing claims. It's dead easy too, since the parser is already Unicode aware for strings and comments anyway, so most take the jump.

And there might be a benefit for certain users.

But I personally will only deal with code written with English identifiers. I don't care if you need my help with your piece of code or if your library is just awesome and I could gain much by using it: if I cannot understand it, I'll just have to ignore it.

  • So you're one of those willing to bake in historical de facto realities into de jure ones (pardon the lack of accents, nobody seems to care these days)?
    – Milind R
    Commented Dec 1, 2018 at 18:26
  • @MilindR: I am one of those who think the world would be a better place if everyone spoke the same language; and I am pragmatic enough to consider English for the role, despite being French. I might be convinced that a subset of Unicode could be helpful in general (Greek letters, for mathematics/physics). I understand that for teaching programming, a programming language where the student can express identifiers in their own language is helpful; this does not require that any and all languages support full Unicode identifiers however. It's my personal opinion, make of it what you will :) Commented Dec 1, 2018 at 19:35

Of course, every modern compiler must deal with Unicode source code today. For example, string constants may need to contain Unicode characters. But once this is achieved, why not allow unicode identifiers also? It's no big deal unless your compiler code depends on characters being 7-bit codes.

But the OP is right insofar: It is now possible that a Hindi speaking Indian must maintain code with russian identifiers and arabic comments. What a nightmare for the poor Chinese who is supposed to do the quality check and who can't read any of the above 3 alphabets!

Hence, it is now an organizational tasks to make sure a programs identifiers and comments are written in a common language. I can't help it but I think this is going to be english for some time to come.

  • A problem with allowing Unicode identifiers is that it allows source code to contain information which is semantically important but not printable. For example, if a class declares field А, its constructor accepts parameter Α, and a statement in the constructor says var x = A.boz();, would A refer to the field, the parameter, or perhaps something else? How could one tell?
    – supercat
    Commented Apr 15, 2014 at 17:04
  • 1
    Yes, but then, only a few characters look alike and then it is, as so often, a matter of style, coding guidelines and quaity assurance that'd have to make sure you don't use 3 different characters that look like A in one place. OTOH, being a freedom-lover I abhor forbidding something just because one is not sure it could possibly be abused by someone.
    – Ingo
    Commented Apr 15, 2014 at 17:18
  • I guess I tend to be of the opinion that programs should either be entered either in human-readable format, or in a format which isn't constrained to being a unified text file (but could include states interconnected with lines, annotations attached to things, etc.). I think there's considerable value to knowing that "what you see is--at least semantically--what is there", and think that programs which are different should look different. If there were standards that forbade the use of identifiers which were close to, but didn't quite match, identifiers in a nearer scope, that might help.
    – supercat
    Commented Apr 15, 2014 at 17:25

I think it makes a lot of sense to allow unicode characters in strings and comments. And if the lexer&parser have to support unicode for that anyway, the compiler writer probably gets unicode character support in identifiers for free, so it would seem like an arbitrary limitation to allow only ASCII characters in identifiers.

  • 9
    Not really. In string literals, non-ASCII characters can be treated as opaque. With identifiers, you need to make a decision about which characters are valid, and whether to normalize them (e.g., is vár the same as vár?)
    – dan04
    Commented Dec 17, 2011 at 3:49

How are you going to type ASCII identifiers on a Chinese keyboard? A few language keywords is one thing, and having to do your whole code that way is another.

Programmers should have the right and ability to call their variables whatever they want. It's none of your business what language that's in.

If you feel so confused reading code with identifiers that have symbols from other people's languages in them, then I'm sure that you exactly understand how confused they feel when they have to use identifiers with symbols from your language in.

  • 4
    I'm typing this message using a "Russian" keyboard. I've googled Chinese keyboard (goo.gl/U1q0m) and I don't really see any difference with the Russian one (goo.gl/af04R). Notice, by the way, that both of them have Latin layout alongside with the native one. Commented Nov 13, 2011 at 18:08
  • 2
    Let's say I use identifiers using Cyrillic. But what about the Chinese maintainig my code? Say, he is familiar with Latin letters, but now he is made to handle a completely different character set! Not to mention Arabic ornate lettering and etc. Commented Nov 13, 2011 at 18:12
  • 2
    3rd paragraph is exact reason to use english only, isn't it? Commented Nov 13, 2011 at 19:47
  • 9
    @Egor: That's a reason for a team or project manager to make a rule. But not a reason for a language or implementation to enforce it. A team or company can always choose to restrict identifiers further- they can't choose to expand the available set. That's why the original set should be as large as possible.
    – DeadMG
    Commented Nov 14, 2011 at 8:00
  • 3
    "How are you going to type ASCII identifiers on a Chinese keyboard?" - exactly the same as on an English keyboard, actually. You chose a bad example; Chinese (and Japanese) are typically entered as english letters describing the pronounciation, then a list of matching Chinese/Japanese is displayed from which the user can select the correct one if the default is not correct (modern systems use context analysis to ensure that it usually is). Commented Nov 21, 2011 at 12:59

According to PEP 3131 -- Supporting Non-ASCII Identifiers dated in 2007, the first part of Rationale states:

Python code is written by many people in the world who are not familiar with the English language, or even well-acquainted with the Latin writing system. Such developers often desire to define classes and functions with names in their native languages, rather than having to come up with an (often incorrect) English translation of the concept they want to name. By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves.

I haven't investigated other languages yet, but it should be among the reasons they added the support.


It would really make life easier (for some of us, anyway) if the compiler would not support Unicode. Right-to-left identifiers are awful. Combined Roman alphabet and right-to-left Unicode identifiers are even worse.

The bad thing about non-support is that certain GUI wizards take the text you put in for an item and automatically use that text as the item's identifier. So what exactly would they do with Unicode text on those items? No easy answer, I'm afraid.

Unicode right-to-left comments can be funny, too. For example, in VS 2010, XML comments display (correctly) as RTL in the code... but when you use Intellisense to pull up the identifier elsewhere in code, the tooltip displays (incorrectly) LTR. Better, perhaps, if there were no support in the first place? Again, not an easy call.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.