Should you use international identifiers in Java/C#?

Question

C# and Java allow almost any character in class names, method names, local variables, etc.. Is it bad practice to use non-ASCII characters, testing the boundaries of poor e

Answer 1

As already pointed out, unless method names mostly match the language, it is a bit weird to constantly switch languages while reading.

For the Scandinavian languages & German, which I can speak and thus speak for, I would at least recommend using standard substitutions, ie.

ä/æ -> ae, ö/ø -> oe, å -> aa, ü -> ue

etc. just in case as others may find it difficult to type the original letters without keyboard/keymap changes. Think if you suddenly had to work with a codebase where the developers used a third language (for instance including the French ç) and didn't do this.. Switching between more than 2 keymaps to type efficiently would be painful in my experience.

Answer 2

It depends:

• Does your team conform to any existing standards that require your using ASCII?
• Is your code ever going to be feasibly reused or read by someone who doesn't speak your native language?
• Do you envision a scenario where you'll need to ask for help online and will therefore not be able to copy-paste your code sample in as-is?
• Are you certain your entire suite of tools support code encoding?

If you answered 'yes' to any of the above, stay ASCII only. If not, go forward at your own risk.

Answer 3

I would stick to ASCII characters because if anyone in your development team is using an SDK that only supports ASCII or you wanted to make your code open source, alot of problems could arise. Personally, I would not do it even if you are not planning on bringing anyone who doesn't speak the language in on the project, because you are running a business and it seems to me that one running a business would want his business to expand, which in this day and age means transcending national borders. My opinion is that English is the language of the realm, and even if you name your variables in a different language, there is little to no point to use any non-ASCII characters in your programming. Leave it up to the language to deal with it if you are handling data that is UTF8: my iPhone program (which involves tons of user data going in between the phone and server) has full UTF8 support, but has no UTF8 in the source code. It just seems to open such a large can of worms for almost no benefit.

Answer 4

There is another hazzard to using non-ASCII characters, though it will probably only bite in obscure cases. The allowed characters are defined in terms of the methods Character.isJavaIdentifierStart(int) and Character.isJavaIdentifierPart(int), which are defined in terms of Unicode. However, the exact version of Unicode used depends on the version Java platform, as specified in the documentation for java.lang.Character.

Since character properties change slightly from one Unicode version to the next, it's possible (but probably very unlikely) you could have identifiers that are valid in one version of Java, but not in the next.

Answer 5

Here's an example of where I've used non-ASCII identifiers, because I found it more readable than replacing the greek letters with their English names. Even though I don't have θ or φ on my keyboard (I relied on copy-and-paste.)

However these are all local variables. I would keep non-ASCII identifiers out of public interfaces.

Answer 6

Part of the problem is that the Java/C# language and its libraries are based on English words like if and toString(). I personally would not like to switch between non-English language and English while reading code.

However, if your database, UI, business logics (including metaphors) are already in some non-English language, there's no need to translate every method names and variables into English.