一部のプログラミング言語で大文字と小文字が区別されるのはなぜですか？

コードを難読化することを除いて、プログラミング言語では大文字と小文字を区別することはありません。

なぜこれをプログラミング言語で実装するのですか？

更新：

あなたが知っている人がこれについて声明を出したようです。

大文字小文字の折り畳みは英語ではかなり些細なことですが、他のいくつかの言語ではそうではありません。ドイツのプログラマーがß変数名に使用する場合、大文字の同等物を何と考えますか？参考までに、「ß」は小文字でのみ使用されます。OTOH、「ss」は同等です-コンパイラーはそれらに一致する義務があると考えますか？ユニコードを使用すると、発音区別符号が事前に構成された文字と発音区別符号を個別に組み合わせるなど、さらに興味深い問題が発生します。次に、2つだけではなく、多くの文字の3つの別々の形式を使用したアラビア語のスクリプトにアクセスします。

暗黒時代には、ほとんどのプログラミング言語は、ほとんどの場合、大文字と小文字を区別しませんでした。たとえば、Pascalは、1文字あたり6ビット（合計64コード）しか使用しないコントロールデータメインフレームで開始しました。そのようなマシンのほとんどは、大文字のみを含む「CDC Scientific」文字セットを使用していました。他の文字セットに切り替えることはできますが、ほとんどは大文字または小文字のいずれかでしたが、両方ではありませんでしたが、両方に同じコードを使用しました。COBOL、FORTRAN、BASICなどの最初の数日間は、古代のBaudotコードにも同じことが当てはまりました。より高性能なハードウェアが広く利用可能になる頃には、大文字と小文字を区別しないため、変更が不可能でした。

時間が経つにつれて、大文字と小文字を区別しないことの本当の難しさがより明確になり、言語設計者はほとんどの場合、人々が大文字と小文字を区別しないことを本当に望む場合、補助ツールで処理することを決定しました（「実現」はおそらくより正確な用語です）言語自体よりも。

少なくともIMOでは、コンパイラは提示されたとおりに正確に入力する必要があります。「これを書いたのに、あなたは本当に何か他のものを意味していると仮定します」。翻訳を行いたい場合は、それを適切に処理するために構築されたツールを使用して、翻訳を個別に行う方が良いでしょう。

誰もが大文字と小文字を区別しないのはなぜですか？VARIABLE1つの場所、Variable別の場所、およびvariable3番目の場所のように単一の変数を参照できると便利なシナリオは何ですか？大文字と小文字を区別しないことは腹立たしいです。そのような大文字と小文字の違いをコードに入れるのVAriableでVariableはなく、誤って入力するとコンパイラエラーが発生します。

結論として、多くのプログラミング言語は、歴史的/慣性的な理由だけでなく、大文字と小文字を区別しないことが悪い考えであるため、大文字と小文字を区別します。

Javaでは、コードでより多くのオプションを提供するために大文字と小文字の区別は使用されませんが、非常に明確で一貫したセマンティックな意味のために使用されます。ClassesLookLikeThis。objectsLookLikeThis。methodsLookLikeThis（）。STATIC_VARIABLES_LOOK_LIKE_THIS。Classes.WithInnerClassesLookLikeThis。それは、より大きな自由を提供するものではありません：それは、そうでなければ過度に冗長な言語であるものにいくつかの情報を簡潔に詰めることを可能にします。

muchoコンパイラとIDEをサポートする明示的に静的に型付けされた言語では、大文字と小文字を区別することは情報（Javaなど）を伝えるための優れた方法だと思います。Rubyのような言語では、大文字と小文字を区別しないRubyを試してみることはできますが、大文字と小文字を区別しないと、さらに多くの予期しない結果が生じる可能性があります。

厳密なシステムでの大文字と小文字の区別は、コードを難読化するものではなく、実際に明確にするものだと思います。考えられるJavaコードを検討してください。

      joe blah = new hUf();

それはかなり明確ですが、どうですか：

      hUf.WTF();

Javaの現状のままでは、これが何であるかが自動的にわかります。大文字と小文字を区別しないJavaでは曖昧なので、クラスをインスタンスから、パッケージをメソッドから区別するために、他のメカニズムに頼る必要があります。そして、そのメカニズムはおそらくあなたがそれがどれほどいのかを吐かせます:)

「許可された」ほど「実装された」とは思いません。大文字と小文字の区別は、文字列比較のデフォルトの状態です。大文字と小文字を区別しない比較を実行し、正しいエラーおよび警告レポートのために元のトークン名を保持するために追加のコードを追加する必要があるため、コンパイラエンジニアが言語の大文字と小文字を区別しないようにするために余分な作業が必要です。

それがほぼ確実にCになった理由です。彼らは、使いやすさを犠牲にして、コンパイラを簡単に実装できるシンプルな言語を作りたかったのです。なぜそれが現代の言語にあるのか？それはもちろんCであるため、それを行う正しい方法でなければなりません！</ sarcasmモード>

それ以外の場合は、構文解析を簡素化し、変数/クラス名の組み合わせを増やすことができます。

大文字と小文字を区別しない解析では、「myClass」と「MyClass」は同じものになるため、一意の識別子を使用する必要があります。あるいは、コンテキストに基づいて使用する識別子を決定できるように、パーサーに複雑なレイヤーを追加する必要があります。

次のようなケースを考えてみましょう。

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

XmlWriterクラスにも「書き込み」という静的メソッドがあるとします。ここで大文字と小文字を区別しない場合、インスタンスまたはクラスで呼び出しますか？

コードをより自己文書化する以外の理由がない場合、大文字と小文字の区別が好きです：

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

私は通常Pythonでプログラミングしますが、C＃の時代に戻って、クラスインスタンスにクラスと同じ名前を付けると非常に便利ですが、小文字（またはキャメル）の場合（他の人が言っているように）：

Thing thing = new Thing();

大文字と小文字を区別しない言語を使用するには、このために他の規則が必要です。つまり、次のようなシギルのようなものです。

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

これは「悪いこと」です。

また、クラスへの参照と変数の使用を見つけるには、grep（大文字と小文字を区別する）が便利だと思います。大文字と小文字を区別しない言語では、これは簡単ではありません。検索と置換についても同じです。

最後に、プログラマーとして、さまざまなケースの単語を見ると、それらは異なるものであることに飛びつきます...私は、コンパイラが助けてくれる動的なスクリプト言語でも、変数のケースが間違っていたバグはめったにありません。

人々は実際に読む前に言葉の形に注意を払っています。大文字と小文字の区別により、シンボル全体の形状がコード全体で一貫します。また、異なる慣習が異なる種類のシンボルを示すと述べている上記のものにも同意します。大文字と小文字の区別と非区別の両方が悪用される可能性があります。悪いプログラマーは常に悪いコードを生成します...彼らは方法を見つけます。

例として言語を取り上げます。なぜ私たちは大文字で文や名前のついたものを始めるのでしょうか...それはまた、Unixのせいですか？

C＃やJavaのような静的に型付けされた言語の場合、実際には値は追加されません。ほとんどの場合、大文字と小文字の不一致を自動的に修正するIDEを持っているため、1日の終わりに偶然「VAriable」と入力すると、IDEがそれを「可変」さらに、MyClass myClass;スタイルの規則を追加すると、大文字と小文字の区別が必ずしも悪いことではないことがわかります。

動的に型付けされた言語の場合、IDEが自動修正を推測するのは難しいため、より多くの議論があるかもしれませんが、動的に型付けされた言語の場合、あなたはすでに（誤字脱字）一貫性のある大文字と小文字の規則を使用しても、それほど大きな負担にはなりません。

そのため、言語で大文字と小文字を区別できない本当の理由はありませんが、言語も大文字と小文字を区別する本当の理由はありません。

「SignOn」と「Signon」に関するScott Hanselmanの記事は、文字列の比較に関するものであり、プログラミング言語とは関係ありません。ユーザーが入力する文字列は常に大文字と小文字を区別せずに比較する必要があることに同意しますが、それはプログラミング言語の識別子とは異なる球技だと思います。

言語が大文字と小文字を区別する場合、私はそれを利用して、数学と科学における従来の事例の使用法を再現します。以下に、いくつかのケースの規則のリストを示します（決して網羅的ではありません）。

• 確率理論では、f通常、小文字は確率密度関数（pdf）をF表し、大文字は対応する累積分布関数（cdf）を表します。
• また、確率理論では、$ Pr [X = x] \ leq 0.05 $のように、大文字は確率変数を表しX、対応する小文字はその実現を表しxます。
• 線形代数では、通常、大文字を使用して行列を参照し、小文字を使用して数値を参照します（例：$ A = [a_ {ij}] $）。
• 単位記号は、リットル（L）と人の名前から派生した単位（ワットはワット、パスカルはPa、ニュートンはNなど）を除き、小文字（たとえば、メートルはm）で表記されます。
• 百万以上を意味する接頭辞の記号は大文字になり（メガ（百万）の場合はM）、百万未満の場合は小文字（ミリ（千）の場合はm）になります。

UnixとCのせいだと思いましたが、それは一種の鶏と卵の問題であり、ギーザーだけが適切に答えることができます。

「イースターバニーが町にやってくる」のニワトリが卵の前に来たかどうかを尋ねられたときに使用した理論的根拠を使用します。ノアの箱舟には鶏がいたので、鶏が最初に来ました。したがって、GCCはUnix上で実行されるため、Unixが最初に登場しました。したがって、Unixは大文字小文字の区別を重視するため、Cとそのすべてのバリアントと子孫、中括弧を強制するものはすべて大文字と小文字を区別します。

おそらく、中括弧と大文字と小文字の区別の間にもリンクがあります。

これまでに挙げた優れた回答に加えて、大文字と小文字の区別により追加の「名前空間」も得られることを指摘したいと思います。たとえば、Perlには、などの特殊なブロックがBEGINありEND、通常のコードとは異なる時間に実行されます（コンパイル時に開始、通常のプログラムが終了した後にEND）。バリアントは予約語ではありません。

さらに先に進んで、言語で将来使用するためにすべて大文字の名前を予約することができます。通常はコードで叫ぶことのない通常のプログラマーに害を及ぼすことはありません。

「ケースセンシティブ」は、技術者が曖昧さを減らすために常に優れています。例としてファイル名を取ります。Windowsのファイル名は大文字と小文字が区別されないのに対し、Windowsのファイル名は大文字と小文字が区別されないため、Windowsファイル名の処理はUnixファイル名よりも困難です。

プログラミングに戻ります。クラス名、メソッド名、変数名については、ほとんどの言語は命名スタイルの規則を強制しません。簡単に「リフレクション」を行うために、「大文字と小文字を区別する」名前を使用して、変換せずに他のデータソースにバインドしたり、同じ名前の異なるケースの問題を処理したりできます。

私はこの暴言に驚いています。m_C＃でアンダースコアまたはフィールド名を使用することを誰も望んでいないので、キャメルケースを使用しています。フィールド名がパブリックプロパティ名と同じ場合、パブリックプロパティ名はPascalケースですそして、バッキングフィールドはキャメルケースであると私は考えています。今のところ問題は発生していません。

特に、一部のプログラマーは、変数名の長さが2文字しかできないBASICの初期の時代から来ています。

それで、キャラクターの数に制限がなければ、彼らはとても幸せになります。また、大文字と小文字の区別もあります。これは、SomeName偶発的に等しくなることSOMENAMEを気にしたくないため、このようなことが原因でバグが発生するためです。