向各种语言实现中添加Unicode标识符支持有什么意义？

我个人发现阅读代码充满了Unicode标识符令人困惑。在我看来，它还阻止了代码的轻松维护。更不用说所有译者的作者为实现这种支持而付出的所有努力。我还不断注意到各种语言实现的（缺点）缺点列表中缺少（或存在）Unicode标识符支持（确实很重要）。我不明白：为什么要这么关注？

当您想到unicode时，就会想到中文或俄语字符，这使您想到了一些在网上看到的用俄语编写的源代码，并且这些源代码不可用（除非您知道俄语）。

但是，如果可以以错误的方式使用unicode，并不意味着它本身在源代码中是不好的。

在使用unicode为特定字段编写代码时，可以缩短代码并使代码更具可读性。代替：

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

你可以写：

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

对于普通开发人员而言，这可能不容易阅读，但对于每天使用数学符号的人来说，仍然很容易阅读。

或者，在进行与SLR摄影相关的应用程序时，请不要：

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

您可以用符号ƒ 代替光圈，其文字更接近ƒ/1.8：

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

这可能不方便：键入通用C＃代码时，我希望编写：

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

而不是：

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

因为在第一种情况下，IntelliSense可以帮助我几乎无需键入就编写整个代码，尤其是无需使用鼠标，而在第二种情况下，我不知道在哪里可以找到这些符号，而不得不依靠鼠标来移动并在自动完成列表中搜索它们。

话虽如此，它在某些情况下仍然有用。currentLens.GetMaximumƒ();我之前的示例中的示例可以依靠IntelliSense，并且输入起来像一样容易GetMaximumAperture，而且更简短，更易读。同样，对于具有许多符号的特定域，键盘快捷键可能比在源代码中的文字等效形式更快地键入符号。

顺便说一句，同样适用于评论。没有人愿意阅读带有中文注释的代码（除非您自己非常了解中文）。但是在某些编程语言中，unicode符号仍然有用。一个示例是脚注¹。

^{¹我当然不会喜欢C＃代码中的脚注，因为在脚注中存在一组严格的样式规则，这些规则要求如何编写注释。另一方面，在PHP中，如果有很多要说明的内容，但是这些内容不是很重要，为什么不将它们放在文件的底部，并在方法的PHPDoc中创建脚注呢？}

我会说：

1. 减轻那些学习编程（例如在学校）并且不懂英语的非专业人员和新手的兴趣。他们无论如何都不编写生产代码。我已经看过很多次代码了：

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

   只是让可怜的人用他的语言写出来：

   double ύψος, βάρος;
   cin >> ύψος >> βάρος;
   

2. 你不喜欢吗

   class ☎ {
   public:
       ☎(const char*);
       void 📞();
       void 🎧(👨);
   };
   
   ☎ ☏("031415926");
   ☏.🎧(👨("Bob"));
   ofstream f;
   f.💾();
   

当然，今天每个现代编译器都必须处理Unicode源代码。例如，字符串常量可能需要包含Unicode字符。但是一旦实现了，为什么不也允许unicode标识符呢？除非您的编译器代码依赖于字符为7位代码，否则没什么大不了的。

但是OP在这方面是正确的：现在，说印地语的印度人可能必须维护带有俄语标识符和阿拉伯语注释的代码。对于应该进行质量检查并且无法阅读上述三个字母中的任何一个的可怜的中国人来说，真是一场噩梦！

因此，确保程序标识符和注释以共同的语言编写是一项组织任务。我无能为力，但我认为这将是英语一段时间。

我认为允许在字符串和注释中使用Unicode字符非常有意义。而且，如果词法分析器和解析器无论如何都必须支持unicode，则编译器编写器可能会免费获得标识符中的unicode字符支持，因此，在标识符中仅允许使用ASCII字符似乎是一个任意限制。

就我而言，这纯粹是出于营销原因。另外可能会使我们的生活更艰难。

营销论点

您知道大多数语言都夸耀的这些疯狂功能吗？一般而言，它几乎没有用，因为它与语言相距甚远，因此它没有提供太多有关特定信息的信息，但是它确实允许人们快速地在桌子上打勾和打叉，并正确地得出结论，因为X的跳动比Y多，所以必须会更好。

好吧，对标识符的Unicode支持就是其中之一。与Lambda支持，泛型编程支持等相比，这没关系...可能不多，绘制表格的人不在乎每行的质量，而只在乎它们的数量。

因此，他们可以夸口：“啊，有了Y，您就没有对标识符的Unicode支持！在X中，我们就这样做了，所以对学生来说，要容易得多！”

可及性的谬误

不幸的是，可访问性的论点是错误的。

哦，我确实知道，能够写成“résultatDuJetDeDé”而不是“ diceThrowResult”（是的，我是法国人）在短期内似乎是一个胜利……但是有缺点！

编程是关于交流

您的程序不仅适用于编译器（它可能不太在乎您使用的标识符），还适用于您的同伴。他们需要能够阅读和理解它。

• 阅读它意味着能够可视化您使用的字符，并不是所有字体都很好地支持Unicode。
• 理解它的确意味着依赖标识符-除非您用冗长的注释来补充它们，但这违反了DRY规则。

当然，您的同学可能说的是您使用的相同的语言（不明显，我曾与德国人，西班牙人，黎巴嫩人和中国人一起上过编程课），您的老师也可能...但是假设您以某种方式在家和突然需要帮助：互联网很棒，您可能会与成千上万知道解决方案的人交谈，但是只有在他们了解您的问题时他们才会回答。而你需要了解他们的回答也是如此。

编程需要理解

可访问性和初始化要求您自己依靠库来为您完成繁重的工作：您不想重新发明IO层以在首次分配时从控制台读取/写入控制台。

• 这些库用哪种语言编写？
• 这些库以哪种语言记录？

如果您回答阿拉伯语的摩洛哥语，我会感到惊讶。

除非您仅依靠自己所助教的课程，并且除非这些课程提供您需要使用的每个库功能的全面文档（甚至可能是翻译的库），否则您将必须学习英语的用法。但是，您可能很早就开始了本编程课程。

英语是...

...程序员（和大多数科学家）的通用语言。

一个人越早承认它，并与之抗争而不是与之抗争，它就能真正地学习和进步。

有些人不可避免地会对此提出反对，并正确捍卫自己说自己选择的语言（通常是他们的母语）的权利，但是，正如Babel所证明的那样，使用的语言越多，沟通越困难。

仍然...

是的，正如一遍又一遍地争论的那样，某些Unicode支持（主要是符号）可以大大简化人们对将数学或物理公式转换为代码的理解。缺点是某些符号会重载，但仍然有帮助。

所以为什么 ？

嗯，正如所说的那样，它与真正的用户便利和营销主张无关。这也非常容易，因为解析器已经对字符串和注释都具有Unicode感知能力，因此大多数人都愿意跳。

对于某些用户来说可能会有好处。

但是我个人只会处理用英文标识符编写的代码。我不在乎您是否需要我的代码帮助，或者您的库是否很棒，并且我可以通过使用它获得很多好处：如果我听不懂它，我将不得不忽略它。

您将如何在中文键盘上键入ASCII标识符？一些语言关键字是一回事，而必须以这种方式完成整个代码是另一回事。

程序员应该有权调用任何变量。使用哪种语言与您无关。

如果你觉得这样混淆阅读与有其他人在他们的语言符号标识代码，那么我敢肯定，你到底了解困惑，他们觉得当他们要使用的符号标识从你的语言。

根据2007年的PEP 3131-支持非ASCII标识符，基本原理的第一部分规定：

Python代码是由世界上许多不熟悉英语甚至不熟悉拉丁语书写系统的人编写的。这样的开发人员通常希望用其母语来定义名称的类和函数，而不是想出（通常是不正确的）要命名概念的英文翻译。通过使用其本国语言的标识符，该语言的使用者之间的代码清晰度和代码可维护性得到了提高。

我还没有研究其他语言，但这应该是他们添加支持的原因之一。

如果编译器不支持Unicode ，这确实会使生活变得更轻松（无论如何，对于我们中的某些人而言）。从右到左的标识符很糟糕。组合的罗马字母和从右到左的Unicode标识符更加糟糕。

不支持的坏处是某些GUI向导会使用您为项目输入的文本，然后自动将该文本用作项目的标识符。那么，他们将对那些项目上的Unicode文本到底做什么呢？恐怕没有简单的答案。

Unicode从右到左的注释也可能很有趣。例如，在VS 2010中，XML注释在代码中（正确）显示为RTL ...，但是当您使用Intellisense在代码中的其他位置提取标识符时，工具提示将（不正确）显示LTR。更好的是，也许如果一开始就没有支持？同样，这并非易事。