一部のプログラミング言語で大文字と小文字が区別されるのはなぜですか？
コードを難読化する以外に、プログラミング言語で大文字と小文字を区別する用途はないと思います。
なぜこれをプログラミング言語で実装するのですか？
更新：
あなたが知っている誰かがこれについて声明を出した のように見えます。
英語では大文字と小文字の折りたたみはかなり簡単ですが、他の一部の言語ではそれほど簡単ではありません。ドイツのプログラマーがß変数名で、同等の大文字をどのように考慮しますか？ちなみに、「ß」はこれまでのみ小文字で使用されます。 OTOH、「ss」is同等-コンパイラにそれらを一致させる義務があると考えますか？ Unicodeに入ると、あらかじめ合成された発音区別符号付きの文字ではなく、組み合わせて発音区別記号を組み合わせた文字など、さらに興味深い問題が発生します。次に、2つだけではなく、3つの別々の形式の多数の文字を含むいくつかのアラビア語のスクリプトを使用します。
暗黒時代には、ほとんどのプログラミング言語はほとんど必要から大文字と小文字を区別しませんでした。たとえば、Pascalは、1文字あたり6ビットのみ（合計64コード）を使用するControl Dataメインフレームで開始しました。そのようなマシンのほとんどは、大文字しか含まれていない「CDC Scientific」文字セットを使用していました。他の文字セットに切り替えることもできますが、ほとんどは大文字または小文字のどちらかでしたが、両方ではありませんでしたが、両方に同じコードを使用していました。 COBOL、FORTRAN、BASICなどの最初の頃には、古代のボードットコードやそのような標準と考えられていたものにも同じことが当てはまりました。より高性能なハードウェアが広く利用できるようになるまでには、大文字と小文字を区別しないため、変更することは不可能でした。 。
時間が経つにつれて、大文字と小文字を区別しないという本当の難しさが明らかになり、言語設計者は主に、人々が本当に大文字と小文字を区別しないことが望まれる場合、補助ツールでより適切に処理することを決定しました（「実現」はおそらくより正確な用語です）。言語自体よりも。
少なくともIMOでは、コンパイラは入力されたとおりに入力を受け取る必要があります。「これを書いたが、他の何かを本当に意図していたと思います」とは判断しないでください。翻訳を実行したい場合は、それを適切に処理するために構築されたツールを使用して、個別に翻訳したほうがよいでしょう。
なぜ誰もが大文字小文字を区別したくないのですか？単一の変数をある場所ではVARIABLE、別の場所ではVariable、3番目の場所ではvariableとして参照できると便利なシナリオはどれですか。大文字と小文字の区別がないことは苛立たしいです。このような大文字と小文字の誤植をコードに入れずに、誤ってVAriableではなくVariableと入力すると、コンパイラエラーが発生します。
結論として、多くのプログラミング言語は、歴史的/慣性的な理由だけでなく、大文字と小文字を区別しないことは悪い考えであるため、大文字と小文字を区別します。
Java大文字と小文字の区別は、コードでより多くのオプションを提供するために使用されるのではなく、非常に明確で一貫した意味上の意味のために使用されます。ClassesLookLikeThis.objectsLookLikeThis.methodsLookLikeThis（）。より大きな自由を提供しない：これにより、一部の情報を、他の方法では過度に冗長な言語に簡潔にまとめることができます。
MuchoコンパイラとIDEをサポートする明示的に静的に型付けされた言語では、大文字と小文字を区別することは情報を伝達する優れた方法です（Javaなど）。Rubyのような言語では、大文字と小文字を区別しないでしょう。さらに予期しない結果が発生しますが、大文字と小文字を区別しないRubyを試すことはできます。
厳密なシステムでの大文字と小文字の区別はコードを難読化しないと思いますが、実際にはそれを明確にします。考えられるJavaコード：
joe blah = new hUf();
それはかなり明確ですが、どうですか：
hUf.WTF();
Java as-it-isでは、これが何であるかが自動的にわかります。大文字と小文字を区別しないJavaではあいまいであるため、インスタンスからクラスをメソッドからパッケージに区別するための他のメカニズムに。そして、そのメカニズムはおそらくそれがどれほど醜いかで嘔吐させるでしょう:)
「許可」ほど「実装」されたとは思いません。大文字と小文字の区別は、文字列比較のデフォルトの状態です。大文字と小文字を区別しない比較を実行し、正しいエラーと警告のレポートのために元のトークン名を保持するために追加のコードを追加する必要があるため、コンパイラエンジニアが言語の大文字と小文字を区別しないようにするための追加の作業が必要です。
それがほぼ確実にCで終わった理由です。彼らは、使いやすさを犠牲にして、コンパイラーの実装が簡単な単純な言語を作りたかったのです。なぜそれが現代の言語にあるのですか？もちろんCなので、必須が正しい方法です！ </皮肉モード>
他に何もない場合は、解析が単純化され、変数/クラス名の組み合わせを増やすことができます。
大文字と小文字を区別しない解析では、 'myClass'と 'MyClass'は同じであるため、一意の識別子を使用する必要があります。または、パーサーに複雑なレイヤーを追加して、コンテキストに基づいてどの識別子が使用されているかを確認できるようにする必要があります。
このようなケースを考えてみましょう：
XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");
XmlWriterクラスにも "Write"という静的メソッドがあるとします。ここで大文字と小文字の区別が適用されていない場合、インスタンスまたはクラスでそれを呼び出していますか？
大文字と小文字の区別が好きな理由は、それだけでコードがより自己文書化されるからです。
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があるので、大文字と小文字の不一致が自動的に修正されます。結局のところ、誤って「VAriable」と入力すると、 my IDEは、それを「変数」に自動修正します。それに追加してMyClass myClass;スタイルの規則と、大文字と小文字の区別が必ずしも悪いことではないことがわかります。
IDEで自動修正を推測するのは難しいため、動的に型付けされた言語の場合、引数が多くなる可能性がありますが、動的に型付けされた言語の場合、すでにそうなっています。一貫性のある大文字と小文字の規則を使用しても、それほど多くの負担が加わらないことを（タイプミスに関して）心配する必要があります。
つまり、言語が大文字と小文字を区別しないnotであるという本当の理由はありませんが、言語がshouldである本当の理由もありません。
Scott Hanselmanによる "SignOn"と "Signon"に関する記事は文字列の比較に関するものであり、プログラミング言語とは関係ありません。 ユーザーが入力するである文字列は常に大文字と小文字を区別せずに比較する必要があることに同意しますが、これはプログラミング言語の識別子とは異なるゲームだと思います。
言語で大文字と小文字が区別される場合、私はそれを利用して、数学と科学における従来の大文字と小文字の使い方を再現します。以下は、いくつかのケースの規則のリストです（決して網羅的ではありません）。
- 確率論では、小文字の
fは通常確率密度関数（pdf）を表し、大文字のFは対応する累積分布関数（cdf）を表します。 - また、確率論では、大文字は確率変数
Xを示し、対応する小文字は$ Pr [X = x]\leq 0.05 $のようにそれらの実現xを示します。 - 線形代数では、大文字は一般的に行列を参照するために使用され、小文字は一般的に数値を参照するために使用されます（例：$ A = [a_ {ij}] $）。
- 単位記号は、リットル（L）と人の名前から派生した単位（Wはワット、Paはパスカル、Nはニュートンなど）を除き、小文字で表記されます（例：メートルはm）。
- 100万以上を意味する接頭辞の記号は大文字（メガ（百万）の場合はM）で、100万未満の場合は小文字（ミリ（千）の場合はm）です。
私はそれがUnixとCのせいだと思っただけです-しかし、それは一種の鶏と卵の問題であり、ギーザーだけが正しく答えることができます。
「イースターバニーが町にやってくる」のニワトリが卵の前に来たかどうか尋ねられたときの根拠を使用します。ノアの箱舟にはニワトリがいたので、ニワトリが最初に来ました。したがって、GCCはUnixで実行されるため、Unixが最初に来ました。つまり、Unixは大文字と小文字の区別が非常に大きいため、Cとそのすべてのバリアントと子孫、中括弧を課すものはすべて大文字と小文字を区別します。
中かっこと大文字と小文字の区別にも関連があると思われます。
「大文字と小文字を区別する」は、技術者にとって曖昧さを減らすために常に優れています。例としてファイル名を取ります。 Windowsのファイル名は大文字と小文字が区別されますが、Unixのファイル名は大文字と小文字が区別されるため、Windowsのファイル名の扱いはUnixのファイル名よりも厄介です。
プログラミングに戻る。クラス名、メソッド名、変数名の場合、ほとんどの言語は命名スタイルルールを適用しません。 「リフレクション」を簡単にするために、「大文字と小文字を区別する」名前を使用して、変換せずに他のデータソースにバインドしたり、同じ名前の問題を別のケースで処理したりできます。
これまでの優れた回答に加えて、大文字と小文字を区別することで「名前空間」も追加されることを指摘しておきます。たとえば、PerlにはBEGINやENDのような特別なブロックがあり、通常のコードとは異なるタイミングで実行され（コンパイル時に開始、通常のプログラムが終了した後に終了）、それらをすべて- capsはそれらを目立たせ、小文字のバリアントは予約語ではないことを意味します。
さらに進んで、言語で将来使用するためにすべて大文字の名前を予約することができ、通常はコードで叫ぶことのない通常のプログラマに害を及ぼすことはありません。
私はこの怒りに驚いています。 C＃のフィールド名にアンダースコアまたはm_を使用したくないので、キャメルケースを使用しました。フィールド名がパブリックプロパティ名と同じ場合は、パブリックプロパティ名はPascalケース、バッキングフィールドはキャメルケースです。「そうです」と思います。これは、プログラミングコミュニティ全体が望んでいるようです。今のところ問題は発生していません。
特に、一部のプログラマーはBASICの初期の頃から来ており、変数名の長さは2文字までです。
それで、キャラクターがいくつになっても、とても幸せになります。また、大文字と小文字を区別します-SomeNameが誤ってSOMENAMEと等しくなることを気にして、このようなことが原因でバグを発生させたくないためです。