26

C# 和 Java 几乎允许在类名、方法名、局部变量等中使用任何字符。使用非 ASCII 字符是不是不好的做法，测试糟糕的编辑器和分析工具的边界，让某些人难以阅读，还是美国的傲慢是唯一反对的论据？

4

11 回答 11

35

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

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

于 2008-09-14T20:38:19.530 回答
14

我想说这完全取决于谁在编写代码库。

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

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

于 2008-09-14T20:31:55.850 回答
13

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

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

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

于 2008-09-16T06:25:21.250 回答
9

我曾经在一个开发团队工作，他们很乐意用任何命名（以及任何其他编码）约定来擦屁股。信不信由你，不得不处理代码中的 ä 和 ö 是我辞职的一个促成因素。虽然我是芬兰人，但我更喜欢使用美式键盘设置编写代码，因为花括号和方括号在芬兰键盘上写起来很痛苦（尝试使用右 alt 和 7 和 0 来表示大括号）。

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

于 2008-09-14T20:55:59.380 回答
4

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

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

于 2009-09-11T23:54:49.553 回答
3

这取决于：

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

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

于 2008-09-14T20:34:56.183 回答
2

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

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

于 2008-09-14T20:34:48.620 回答
2

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

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

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

于 2008-09-14T20:42:34.530 回答
1

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

于 2010-07-06T10:10:53.463 回答
0

使用非 ASCII 字符还有另一个危险，尽管它可能只会在晦涩难懂的情况下咬人。允许的字符是根据Character.isJavaIdentifierStart(int)和Character.isJavaIdentifierPart(int)方法定义的，它们是根据 Unicode 定义的。但是，使用的 Unicode 的确切版本取决于 Java 平台的版本，如java.lang.Character的文档中所指定。

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

于 2013-08-28T22:49:19.333 回答
0

正如已经指出的，除非方法名称大部分与语言匹配，否则在阅读时不断切换语言有点奇怪。

对于我可以说的斯堪的纳维亚语言和德语，我至少会建议使用标准替换，即。

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

等等，以防其他人可能会发现在不更改键盘/键盘映射的情况下很难键入原始字母。想想如果你突然不得不使用开发人员使用第三种语言（例如包括法语ç）并且没有这样做的代码库。根据我的经验，在两个以上的键盘映射之间切换以有效地打字会很痛苦。

于 2019-01-29T16:55:25.333 回答