你应该在 Java/C# 中使用国际标识符吗？

Should you use international identifiers in Java/C#?

提问by Jason Cohen

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 editors and analysis tools and making it difficult for some people to read, or is American arrogance the only argument against?

C# 和 Java 几乎允许类名、方法名、局部变量等中的任何字符。还是美国的傲慢是唯一反对的论据？

采纳答案by Michael Stum

I would stick to english, simply because you usually never know who is working on that code, and because some third-party tools used in the build/testing/bugtracking progress may have problems. Typing ??ü? on a Non-German Keyboard is simply a PITA, and I simply believe that anyone involved in software development should speak english, but maybe that's just my arrogance as a non-native-english speaker.

我会坚持使用英语，因为您通常永远不知道谁在处理该代码，并且因为在构建/测试/错误跟踪过程中使用的某些第三方工具可能存在问题。打字？？ü？在非德语键盘上只是一个 PITA，我只是相信任何参与软件开发的人都应该说英语，但这也许只是我作为非英语母语人士的傲慢。

What you call "American arrogance" is not whether or not your program uses international variable names, it's when your program thinks "W?hrung" and "Wahrung" are the same words.

你所谓的“美国傲慢”不是你的程序是否使用国际变量名，而是你的程序认为“W?hrung”和“Wahrung”是同一个词。

回答by 17 of 26

I'd say it entirely depends on who's working on the codebase.

我会说这完全取决于谁在代码库上工作。

If you have a small group of developers who all share a common language and you don't ever plan needing anyone who doesn't speak the language to work on the code then go ahead and use whatever characters you want.

如果您有一小群开发人员，他们都使用一种共同的语言，并且您不打算让任何不会说这种语言的人来处理代码，那么请继续使用您想要的任何字符。

If you need to have people of varying cultures and languages working on the code then it's probably best to stick with English since it's the common denominator for just about everyone in the world.

如果您需要让不同文化和语言的人来处理代码，那么最好坚持使用英语，因为它是世界上几乎每个人的共同点。

回答by Eugene Yokota

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

部分问题在于 Java/C# 语言及其库基于英语单词if和toString()。我个人不喜欢在阅读代码时在非英语语言和英语之间切换。

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.

但是，如果您的数据库、UI、业务逻辑（包括隐喻）已经是某种非英语语言，则无需将每个方法名称和变量都翻译成英语。

回答by AlexeyMK

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?

• 您的团队是否符合要求您使用 ASCII 的任何现有标准？
• 您的代码是否会被不会说您母语的人重复使用或阅读？
• 您是否设想过需要在线寻求帮助并因此无法按原样复制粘贴代码示例的场景？
• 您确定您的整个工具套件都支持代码编码吗？

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

如果您对上述任何一项回答“是”，请仅保留 ASCII。如果没有，请自行承担风险。

回答by Orion Edwards

IF you get past the other prerequisitesyou then have one extra (IMHO more important) one - How difficult is the symbol to type.

如果你通过了其他先决条件，那么你就有一个额外的（恕我直言更重要）一个 - 输入符号有多困难。

On my regular en-us keyboard, the only way I know of to type the letter ? is to hold alt, and hit 0227 on the numeric keypad, or copy and paste.

在我的常规 en-us 键盘上，我所知道的唯一输入字母的方法是？是按住alt，然后在数字键盘上按0227，或者复制粘贴。

This would be a HUGE big roadblock in the way of typing quickly. You don't want to slow your coding down with trivial stuff like this if you aren't forced to. International keyboards may alleviate this, but then what happens if you have to code on your laptop which doesn't have an international keyboard, etc?

这将是快速打字的一个巨大障碍。如果你不是被迫的，你不想用像这样的琐碎东西来减慢你的编码速度。国际键盘可能会缓解这种情况，但是如果您必须在没有国际键盘等的笔记本电脑上进行编码，会发生什么？

回答by theiterator

I used to work in a development team that happily wiped their asses with any naming (and for that matter any other coding) conventions. Believe it or not, having to cope with ?'s and ?'s in the code was a contributing factor of me resigning. Though I'm Finnish, I prefer writing code with US keyboard settings because curly and square brackets are a pain to write in a Finnish keyboard (try right alt and 7 and 0 for curlies).

我曾经在一个开发团队工作，他们很高兴地使用任何命名（以及任何其他编码）约定。信不信由你，不得不处理代码中的 ? 和 ? 是我辞职的一个促成因素。虽然我是芬兰人，但我更喜欢使用美式键盘设置编写代码，因为在芬兰键盘上编写大括号和方括号很麻烦（尝试使用正确的 alt 和 7 和 0 表示卷曲）。

So I say stick with the ascii characters.

所以我说坚持使用 ascii 字符。

回答by Thomas Eyde

If your business are non-English speakers, and you think Domain Driven Design has something to it, then there is another aspect: How do we, as developers, use the same domain language as our business without any translation overhead?

如果您的业务不讲英语，并且您认为领域驱动设计有其意义，那么还有另一个方面：作为开发人员，我们如何在没有任何翻译开销的情况下使用与业务相同的领域语言？

That does not only mean translations between languages, say English and Norwegian, but also between different words. We should use the exact same words as our business for our entity classes and services.

这不仅意味着语言之间的翻译，比如英语和挪威语，还包括不同单词之间的翻译。对于我们的实体类和服务，我们应该使用与我们的业务完全相同的词。

I have found it easier to just give in and use my native language. Now that my code use the same words, it's easier to have a conversation with my domain experts. And after a while you get used to it, just like how you got used to code without Hungarian notation.

我发现放弃并使用我的母语更容易。既然我的代码使用相同的词，与我的领域专家进行对话就更容易了。过一段时间你就会习惯它，就像你习惯了没有匈牙利符号的编码一样。

回答by finnw

Here's an exampleof 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.)

这是我使用非 ASCII 标识符的示例，因为我发现它比用英文名称替换希腊字母更易读。即使我的键盘上没有 θ 或 φ（我依靠复制和粘贴。）

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

然而，这些都是局部变量。我会将非 ASCII 标识符排除在公共接口之外。

回答by Chris

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.

我会坚持使用 ASCII 字符，因为如果您的开发团队中的任何人使用仅支持 ASCII 的 SDK，或者您想让您的代码开源，可能会出现很多问题。就我个人而言，即使您不打算让不会说该语言的任何人参与该项目，我也不会这样做，因为您正在经营一家企业，而且在我看来，经营一家企业的人希望他的业务扩展，这在当今时代意味着超越国界。我的观点是英语是领域的语言，即使您用不同的语言命名变量，在您的编程中使用任何非 ASCII 字符也几乎没有意义。如果您正在处理 UTF8 数据，则由语言来处理它：我的 iPhone 程序（涉及到手机和服务器之间的大量用户数据）完全支持 UTF8，但源代码中没有 UTF8。它似乎只是为了几乎没有任何好处而打开如此大的蠕虫罐头。

回答by Andrew

There is another hazzard to using non-ASCII characters, though it will probably only bite in obscure cases. The allowed characters are definedin 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.

使用非 ASCII 字符还有另一个危险，尽管它可能只会在不明确的情况下咬人。允许的字符被定义的方法中的术语Character.isJavaIdentifierStart（INT）和Character.isJavaIdentifierPart（INT） ，其被以Unicode定义的。但是，所使用的 Unicode 的确切版本取决于 Java 平台的版本，如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.

由于字符属性从一个 Unicode 版本到下一个版本略有变化，因此有可能（但可能性很小）您的标识符在一个 Java 版本中有效，但在下一个版本中无效。