Question

自从我了解到clang能够编译用Unicode编写的c ++源文件后，我开始在编写与数学相关的代码时大量使用它。比较

uₙ₊₁ᵖ = A*uₙ + B*uₙ₋₁;
uₙ₊₁ᶜ = π * Aₜₒₜ;
uₙ₊₁ = uₙ₊₁ᵖ + uₙ₊₁ᶜ;

和

u_n1_p = A*u_n + B*u_n_1;
u_n1_c = pi * A_tot;
u_n1 = u_n1_p + u_n1_c;

对我而言，就像白天和黑夜一样：我只是通过阅读它来理解第一段代码，而我根本不想阅读另一段代码

我知道Python3和Ruby允许使用Unicode源文件，所以看起来这个功能正在传播。

可以针对这种做法提出异议：例如：并非所有字体都支持这些字符，您的源文件取决于您正在使用的编码，并且您必须从文本编辑器中的某处实际复制/粘贴（例如）Unicode字符。但是我认为可读性的提高非常好。

现在您可以在this page上看到，并非所有（甚至拉丁语）字母都可用于下标和上标。更糟糕的是，这些绝对不适用于在源文件中编写数学的用法（参见here）

因此我的问题是：

您是否将Unicode用于与数学相关的代码？您如何看待这种用法？
有没有办法在下标或上标中翻转字符？（类似于组合用于变音符号的字符）

Answer 1

除非

，否则我会说不

仅限内部代码，且不会污染公共API
整个团队同意这是非常有益的
仅限数学密集型函数（不适用于相当简单的数学任务）
从业务逻辑/接口代码中分离出来
仅限于unicode的某个子集（可能只是下标和希腊符号）

即使满足所有这些要求，我也会减轻使用的麻烦，增加可读性并倾向于坚持使用ASCII。

请确保您向团队提供有关何时可以接受的严格指导，以便您不会陷入每个for循环使用iₙ的情况。

我的电脑似乎不喜欢您使用的'LATIN SUBSCRIPT SMALL LETTER N'（U + 2099）字符，只是将其呈现为极大降低可读性的框。确保您的工具/字体支持这种编辑方式。

PEP8 states unicode字符不应该用于标准库中的标识符 - 它们可能有充分的理由。

总结 - 除非你有充分的理由，否则只有在单独的数学密集型模块中。我想我可以确信它在某些情况下很有价值。

Answer 2

我对OP的问题是：ever since多长时间？

好问题。 Unicode已经和我们在一起很长一段时间了，那么为什么要编程被强制使用美国风格的ASCII而没有任何重音？在工作和学习C＃和Javascript时，我发现这些语言具有Unicode感知能力。 C＃在System.Math中定义了两个有趣的常量：

    //     Represents the natural logarithmic base, specified by the constant, e.
    public const double E = 2.7182818284590451;

    //     Represents the ..., specified by the constant, π.
    public const double PI = 3.1415926535897931;

这里我们看到π的unicode注释，但不是ℯ。如果两个常量都带有unicode标识符，能够编写，例如：

，这不是很好吗？

 double circumference = 2 * Math.π * r;

e的情况很复杂，因为它经常与指数一起使用，总是难以在一行上表达。此外，ℯ（U + 212F），对数基数和℮（U + 212E）（电子电荷）的unicode表示是可疑的。我无法确切地找到基本电荷的确切正确的unicode确认。

我想除了通常的希腊字符之外，没有真正的Unicodes用于这种常量，应该在Unicode希腊字母表中查找。

我对System.Math的结论是保留ascii标识符E和PI，并添加unicode标识符π。

关于OP问题1，我还建议使用希腊字母表而不是强制使用变量进行数学运算。 φ到phi，δ到delta或d，如：

var x = 2 * π * sin(φ);

这样的代码绝对不比ascii版本更难维护。

然而，我喜欢从ascii到unicode的技术进步，我仍然建议用普通的us-english编程。西班牙语，匈牙利语的变量名称和评论，不，谢谢。也许对原始程序员来说很好，但这使得协作变得更加困难。（披露：我不是母语为英语的人）而且，至少在C＃和Javascript中，保留字只有英文：for，if，else，... < / p>

所以：保持简单：希腊字母表的unicode：是的，对于数学符号。多语言的Unicode（重音符号）：不，请使用英语。

超级/下标：实际上我觉得这个好主意。我看到的问题在于复杂性：下标中的n+1旨在作为变量名称的一部分，但看起来像是C＃/ C ++操作。只是不要在名称中使用类似运算符的字形。

在源文件中使用Unicode并且缺少unicode符号

2 个答案: