さまざまな言語実装に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.∞, α₂);

これは平均的な開発者には読みにくいかもしれませんが、毎日数学記号を使用する人には読みやすいです。

または、次の代わりに、一眼レフ写真に関連するアプリケーションを実行する場合：

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文字を含める必要がある場合があります。しかし、これが達成されたら、ユニコード識別子も許可しないのはなぜですか？コンパイラコードが7ビットコードである文字に依存しない限り、大したことではありません。

しかし、OPは今のところ正しい：ヒンディー語を話すインド人は、ロシアの識別子とアラビア語のコメントでコードを維持しなければならない可能性がある。品質チェックを行うことになっていて、上記の3つのアルファベットのいずれも読めない貧しい中国人にとって、なんと悪夢でしょう！

したがって、プログラムの識別子とコメントが共通の言語で記述されていることを確認することは、現在では組織的なタスクです。私はそれを助けることができませんが、これは今後しばらく英語になると思います。

文字列とコメントにユニコード文字を許可することは非常に理にかなっていると思います。とにかくレクサー＆パーサーがそのためにユニコードをサポートする必要がある場合、コンパイラのライターはおそらく識別子でユニコード文字のサポートを無料で取得するため、識別子でASCII文字のみを許可することは任意の制限のように思われます。

私の知る限り、これは純粋にマーケティング上の理由によるものです。さらに、私たちの生活を難しくするかもしれません。

マーケティングの議論

ほとんどの言語が誇るこのクレイジーな機能のリストを知っていますか？一般的にはほとんど役に立たない、なぜならそれは特定の多くの情報を提供しないほど言語から遠く離れているが、ティックとクロスのあるテーブルを素早くドレスアップし、XがYより多くのティックを持っているから良くなります。

さて、識別子のUnicodeサポートはそれらの行の1つです。Lambdaサポート、Genericプログラミングサポートなどと比較して、それは大したことではないかもしれませんが、テーブルを描く人は各行の品質を気にしません。

したがって、彼らは自慢することができます：「ああ、あなたはあなたの識別子のUnicodeサポートを持っていません！Xではそうするので、学生にとってそれははるかに簡単です！」

アクセシビリティの誤り

残念ながら、アクセシビリティの議論は間違っています。

ああ、「diceThrowResult」の代わりに「résultatDuJetDeDé」（はい、私はフランス語です）を書くことができれば、短期的には勝利のように思えるかもしれませんが、欠点があります！

プログラミングはコミュニケーションについてです

あなたのプログラムは、コンパイラー（使用する識別子にあまり注意を払わない可能性がある）だけを対象としているのではなく、フェローも対象としています。彼らはそれを読み、理解できる必要があります。

• それを読むことは、使用した文字を視覚化できることを意味し、Unicodeはすべてのフォントであまりサポートされていません
• それを理解することは、識別子に頼ることを意味します-長いコメントで補足しない限り、それはDRYルールに違反しています。

もちろん、あなたのクラスメートはあなたと同じ言語を話すかもしれません（明らかではないが、私はドイツ人、スペイン人、リバナ人、中国人とプログラミングのクラスを持っていた）、そしてあなたの教師もそうかもしれない...突然助けが必要です：インターネットは素晴らしいです。解決策を知っている何千人もの人々と話すことができますが、彼らはあなたの質問を理解した場合にのみ答えます。そして、あなたも彼らの答えを理解する必要があります。

プログラミングには理解が必要

アクセシビリティとイニシエーションには、ライブラリに基づいてヘビーリフトを行う必要があります。最初の割り当てでコンソールとの間で読み取り/書き込みを行うためにIOレイヤーを再発明する必要はありません。

• それらのライブラリはどの言語で書かれていますか？
• それらのライブラリはどの言語で文書化されていますか？

モロッコのアラビア語と答えたら、驚くでしょう。

あなただけの講義に依存している場合を除き、あなたはに支援し、すべてのライブラリの機能に存在するものの包括的なドキュメントは、あなたは、あなたが使用（そしておそらく翻訳ライブラリ）にする必要がありますでしょう英語のmodicrumを学ぶ必要があります。しかし、とにかく、このプログラミングコースを開始するずっと前に、おそらく既にやっていることでしょう。

英語は...

...プログラマー（およびほとんどの科学者）の共通語。

早くそれを認め、それと戦うのではなく、それに沿って進むと、より早く人は真に学び、進歩することができます。

必然的にこれに反対し、選択した言語（通常は母性言語）を話す権利を正当に擁護する人もいますが、バベルが示したように、使用する言語が多いほど、コミュニケーションが難しくなります。

それでも...

はい、何度も議論されてきたように、一部のUnicodeサポート（主にシンボル）は、数学や物理式をコードに変換する必要がある人にとって理解を非常に容易にします。いくつかのシンボルが過負荷になるという欠点がありますが、それでも解決する可能性があります。

なぜ ？

さて、言ったように、それは実際にユーザーの利便性に関するものではなく、マーケティングの主張に関するものです。とにかく、パーサーは文字列とコメントに対してすでにUnicodeを認識しているので、非常に簡単です。

また、特定のユーザーにとってはメリットがあるかもしれません。

しかし、個人的には、英語の識別子で書かれたコードのみを扱います。あなたがあなたのコードで私の助けを必要とするか、あなたのライブラリがちょうど素晴らしいのか、それを使用することで多くを得ることができるかどうかは気にしません：私がそれを理解できない場合、私はそれを無視する必要があります。

中国語キーボードでASCII識別子をどのように入力しますか？いくつかの言語キーワードは一つのことであり、コード全体をそのように行わなければならないことは別です。

プログラマは、自分の変数を好きなように呼び出す権利と能力を持っている必要があります。あなたのビジネスでは、どの言語が使用されているかは関係ありません。

他の人の言語のシンボルを含む識別子を使用してコードを読むのが非常に混乱していると感じた場合、あなたの言語のシンボルを含む識別子を使用しなければならないときに彼らが感じる混乱を正確に理解していると確信しています。

PEP 3131- 2007年の非ASCII識別子のサポートによると、根拠の最初の部分は次のように述べています：

Pythonコードは、英語に精通していないか、ラテン語の書記体系に精通している世界中の多くの人々によって書かれています。そのような開発者は、名前を付けたい概念の（多くの場合、誤った）英語翻訳を考え出すよりも、母国語で名前を付けてクラスと関数を定義することを望みます。ネイティブ言語で識別子を使用することにより、その言語の話者の間でコードの明快さと保守性が向上します。

他の言語についてはまだ調査していませんが、サポートを追加した理由の1つであるはずです。

コンパイラがUnicodeをサポートしない場合、（とにかく私たちの一部にとって）本当に楽になります。右から左の識別子はひどいです。ローマ字アルファベットと右から左へのUnicode識別子の組み合わせはさらに悪いです。

非サポートの悪い点は、特定のGUIウィザードがアイテムに入力したテキストを受け取り、そのテキストをアイテムの識別子として自動的に使用することです。では、それらのアイテムのUnicodeテキストを使用して、正確に何をするでしょうか？簡単な答えはありません、私は恐れています。

Unicodeの右から左へのコメントも面白い場合があります。たとえば、VS 2010では、XMLコメントはコード内でRTLとして（正しく）表示されますが、Intellisenseを使用してコード内の別の場所で識別子をプルアップすると、ツールチップに（誤って）LTRが表示されます。そもそもサポートがなかった方が良いでしょうか？繰り返しますが、簡単な呼び出しではありません。