Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Do you mean names for things, or do you mean special characters like stars, lambdas and middle dots? –  Frank Shearar Nov 14 '11 at 8:11
    
Identifier is usually understood as "names for things" such as variables, classes, functions, etc. Unicode defines which characters are suitable for use in identifiers. Lamdba (λ), being a (greek) letter, is suitable for use in identifiers. It's up to languages to determine whether λ is the same as Λ (Latin isn't the only script with upper- and lowercase.) –  MSalters Nov 14 '11 at 12:35
2  
lol ! Did you know that a world exists outside english speaking contries ? Amazign discovery, isn't it ? –  deadalnix Nov 21 '11 at 11:00
3  
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 Nov 21 '11 at 14:35
4  
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. –  Matthieu M. Jan 1 '12 at 13:23

7 Answers 7

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?

share|improve this answer
    
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 Apr 10 at 20:11
    
@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. –  MainMa Apr 11 at 6:31
    
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 Apr 15 at 12:59
    
@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. –  MainMa Apr 15 at 16:40
    
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 Apr 15 at 16:55

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.

share|improve this answer
    
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 Apr 15 at 17:04
    
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 Apr 15 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 Apr 15 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.

share|improve this answer
6  
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 Dec 17 '11 at 3:49

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.

Still...

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.

share|improve this answer

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 ☎ {
    public:
        ☎(const char*);
        void 📞();
        void 🎧(👨);
    };
    
    ☎ ☏("031415926");
    ☏.🎧(👨("Bob"));
    ofstream f;
    f.💾();
    
share|improve this answer

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.

share|improve this answer
3  
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. –  Egor Tensin Nov 13 '11 at 18:08
1  
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. –  Egor Tensin Nov 13 '11 at 18:12
    
No offence here, anyway. I'm not really familiar with the way the average Chinese programmer inputs his identifiers. –  Egor Tensin Nov 13 '11 at 18:13
1  
3rd paragraph is exact reason to use english only, isn't it? –  Anton Barkovsky Nov 13 '11 at 19:47
7  
@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 Nov 14 '11 at 8:00

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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