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

2023年5月4日 494次阅读

自从我了解到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用于与数学相关的代码？您如何看待这种用法？
>有没有办法在下标或上标中翻转字符？ (类似于组合用于变音符号的字符)

最佳答案 我会说不,除非

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

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

确保你在可接受的时候给你的团队严格的指导,这样你就不会陷入每个for循环使用iₙ的情况.

我的电脑似乎不喜欢你使用的’LATIN SUBSCRIPT SMALL LETTER N'(U 2099)字符,只是把它渲染成一个盒子,大大降低了可读性.确保您的工具/字体支持这种编辑方式.

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

总之 – 除非你有一个非常好的理由,否则只有在单独的数学密集模块中.我想我可以确信它在某些情况下很有价值.

点赞