多くの言語で大文字と小文字が区別されるのはなぜですか？
多くの言語で大文字と小文字が区別されるのはなぜですか？
それは単に相続の問題ですか？ C++は大文字と小文字を区別します、Java C++は大文字と小文字を区別します、など？またはその背後にもっと実用的な理由がありますか？
Unix。
Unixは大文字と小文字を区別し、Unixで使用するために開発された非常に多くのプログラミング言語は大文字と小文字を区別していました。
コンピュータは寛容ではありません-大文字は小文字と同じものではなく、まったく異なります。そして、処理サイクル、RAMなどが高価だったとき、コンパイラとコンピュータを「寛容」にする努力の価値があるとは見なされていませんでした。人々はただ物事を手に入れようとしていました。作業。
Visual Basic のようなものが登場するまで、大文字と小文字を区別しないことが実際には役に立たなかったことに注意してください。企業が大衆をプログラムすることは収益にとって良いことであるという概念に投資し始めたら（つまり、Windowsにもっと多くのプログラムがある場合、Microsoftはより多くのお金を稼ぎます）言語はより親しみやすく、より寛容になり始めました。
「その言語の作者はその方が良いと思っていたので」よりも良い答えが得られるとは思いません。個人的には正しいと思います。同じソースファイルのどこかにこれらの行を見つけるのは嫌です（そして同じオブジェクト+メソッドを参照します）...
SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();
誰もがこれを見て喜んでいるとは思わない...
考慮すべき興味深い点の1つは、英語でも大文字と小文字が区別されることです。 （これはほとんどの自然言語に当てはまると思いますが、すべてに当てはまるとは限りません。）
次の間に大きな違いがあります（とにかく、私が住んでいる場所、レディングの町の近く）：
私は読書が好きです。
そして
私は読書が好きです。
同様に、多くの人がdo大文字を誤って使用し、通常はその意味を理解できますが、そのような記述が正しいと見なされるわけではありません。もちろん、私はこの種のことに関してはこだわりを持っています。もちろん、すべてを自分で正しく行うとは限りません。それがプログラミング言語の大文字と小文字の区別の継承の一部であるかどうかはわかりませんが、そうである可能性があると思います。
プログラミング言語で大文字と小文字を区別することの明確な利点の1つは、テキストが文化的に鈍感になることです。ソースファイルにどのテキストエンコーディングが使用されているかをコンパイラにときどき説明しなければならないのは十分に悪いことです-どのテキストエンコーディングが使用されているかを指定する必要がありますcultureさらに悪いでしょう:(
これは、開発者にとっても言語構文仕様にとっても、実際には非常に実用的です。小文字と大文字の区別により、識別子の命名に非常に表現力が加わります。
言語構文の観点から、特定の識別子を小文字または大文字で開始するように強制できます（たとえば、Javaクラス名）。これにより、解析が容易になり、構文がきれい。
開発者の観点からすると、これにより、非常に多くの便利なコーディング規則が可能になり、コードがより明確で理解しやすくなります。
私の推測では、大文字と小文字の区別により名前空間が拡大します。次のような素敵なトリック
MyClass myClass;
大文字と小文字を区別しないコンパイラでは不可能です。
ケースの折り畳みは英語でのみ簡単です（そしてすべての文字が128未満の場合）。ドイツ語 szまたは "sharp s"（ß） は、ISO8859-1文字セットに大文字のバリアントがありません。それは約 議論の10年 の後にUnicodeで1つだけ受け取りました（そして今、すべてのフォントを更新する必要があります...）。漢字とひらがな（日本語のアルファベット）は小文字すら知りません。
この混乱を避けるために、このUnicodeの時代でも、大文字と小文字を区別するおよびユニコード識別子を許可することは賢明ではありません。
解析とコンパイルが非常に高価で、一晩かかると、大文字と小文字を区別する必要がなければ、コンパイラにとって有利でした。
ケースを介してのみ一意である識別子が存在するようになると、元に戻すことは非常に困難になりました。多くの開発者がそれを気に入っており、それを元に戻したいという大きな願望はないようです。
ExpertSexChange
これは、回答を読むためにお金を払わなければならないStackOverflowの競合相手だと思います。うーん...大文字と小文字を区別しないため、サイト名の意味があいまいです。
これは、言語で大文字と小文字が区別される理由です。あいまいさが少なくなります！プログラマーにとっての曖昧さは厄介だと考えられています。
大文字と小文字の区別は、命名規則を使用することで言語の可読性を高めます。書けない
Person person = new Person("Bill");
言語で大文字と小文字が区別されない場合。コンパイラはクラス名と変数名を区別できないためです。
また、Person、person、PersoN、PeRsOn、およびPERSONがすべて同等のトークンであると、頭痛の種になります。 :)
iの大文字の形式は何ですか？ [〜＃〜] i [〜＃〜]（U + 0049）またはİ（U + 0130）？
大文字と小文字はロケールによって異なります。
彼らはカエルの箱のように愚かですなので、このスレッドの反対の視点に与えられた正確な理由のために（私はそれが何であるかを尋ねるつもりはありません。木のための木材とそのすべて）。
FOOBAR = FooBar = foobarの場合、規則を選択でき、他のコーダーも同じことができます好みを共有しているかどうかに関係なく。混乱はありません。
また、大文字が異なっていても、同じファイル内に同じ名前の定数、関数、変数がすべて含まれている天才のストロークを回避することはできません。繰り返しますが、混乱はありません。
あなたはあなたの変数をウェブサイトと呼び、彼らは彼らのウェブサイトと呼びます、そしてどのシステムが混乱しますか？スキャンしているときも、簡単にキャッチすることはできません。
ルックアップに関しては、ルックアップする前に名前を小文字に変換するのは本当にはるかに多くの処理ですか？独自の時期尚早な最適化を行うことは1つのことであり、選択した言語の開発者にそれを期待することは、まったく別のレベルの要点を見逃すことです。
...それでも、大文字と小文字を区別するというこれらすべての回答は混乱を減らします。 ため息
多くの（プログラミングではない）言語（たとえば、ローマ字を使用するヨーロッパ言語）では大文字と小文字が区別されるため、これらの言語のネイティブスピーカーが大文字と小文字を区別するのは自然なことです。
プログラミング言語そうではない大文字と小文字を区別するという考え自体は、初期世代のハードウェア（5ビットの文字コードを使用するプレコンピューターテレタイプマシンを含む）の制限から生じる歴史的な成果物です。
大文字と小文字を区別しない言語を主張する人々は、区別できないはずです
IAmNowHere
から
IAmNowhere
（冗談です！ ;-)
Common LISPもあります。これは、多くの人が大文字と小文字を区別しないと誤って信じている大文字と小文字を区別する言語です。リスナーに(car x)と入力すると、処理のために(CAR X)に変わります。小文字の名前で記号を定義することは可能ですが、|lower-case-symbol|のようなもので引用する必要があります。したがって、(car x)または(CAR X)または(Car X)の入力はすべて同じように機能します。
（Franz LISPは、ある時点で、リスナーが大文字と小文字を区別せず、CLキーワードが小文字になる、いわゆる「モダン」大文字を導入していました。そこで何が起こったのかを知るのに十分なフォローはしていませんでした。）
.NET Framework開発者ガイドから 大文字の表記法 、大文字と小文字の区別：
大文字の使用に関するガイドラインは、識別子を読みやすく、認識しやすくするためだけに存在します。ケーシングは、ライブラリ要素間の名前の衝突を回避する手段として使用することはできません。
すべてのプログラミング言語で大文字と小文字が区別されると想定しないでください。ではない。名前は大文字と小文字だけで異なることはできません。
キャップがない場合はどうやって怒鳴りますか？！ AHHH！
あなたは表現力がなければなりません。しかし、正直なところ、世界中のすべての人々の中で、プログラミングロジックを扱う人々は、違いは実際には違いであると最初に主張するでしょう。
文字の大文字 普遍的な概念ではありません 。 JavaはUnicodeを使用するため、大文字と小文字を区別しないJavaが必要な場合は、プログラムがコンパイルされたロケールに応じてプログラムの意味が変わる可能性があります。
ほとんどの言語では、整数リテラルの途中にドットやコンマ（またはアポストロフィやスペース）を配置することはできません。これもロケールに依存するためです。
大文字と小文字の区別は、大文字と小文字の一貫性にはあまり役立ちません。
Foo.Bar
foo.Bar
fOO.bAR
大文字と小文字を区別しない言語で、エディタによって簡単に自動的に修正できます。大文字と小文字を区別する言語で修正する場合、合法である可能性があるため、修正が難しくなります。エディターは、最初にfoo.BarとfOO.bARが存在するかどうかを確認する必要があります。また、変数の宣言を忘れるのではなく、間違った大文字と小文字を入力したと推測する必要があります（FooはfOOとは異なるため）。
大文字と小文字の区別をサポートするために私が見たすべての例は、悪い、説明のつかないコードを書きたいという願望に基づいています。例えば「日付」と「myDate」の引数-これらは両方とも等しく説明的ではないそして悪い習慣です。 birthDate、hireDate、invoiceDateなど、実際の名前を付けることをお勧めします。そして、彼らの正しい心の中で誰が次のようなコードを書きたいと思うでしょう：
Public Class Person
Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
Public person As Person = person.PERSON
End Class
驚くべきことに、これは完全に有効なケースですin大文字と小文字を区別するVB.Netコード。大文字と小文字を区別することで、優れたプログラミング手法にさらにひどく従わないようにすることができるという考えは、それに対する反論であり、賛成ではありません。
私はこのスレッド全体を読みました。大文字と小文字を区別することで価値を見出したと報告している人は、真の高級言語（定義上、大文字と小文字を区別しない）でプログラミングしたことがないと信じなければなりません。 K＆Rは、Cが中間レベルであることを認めています。 Pascal、Delphi、Lazarus、ADAなどでプログラミングした後、非常に読みやすいコードは簡単に記述でき、大文字と小文字を区別する簡潔な構造に執着することなくすばやく実行できることがわかります。結局のところ、読みやすさは主題に関する最初で最後の言葉です。コードはコンピューターではなく人間のために書かれています。大文字と小文字を区別しないコードでデバッグしても問題ありません。中級レベルの言語に移行すると、大文字と小文字の区別に利点がないことがわかります。ただし、大文字と小文字の区別のデバッグにかなりの時間が費やされ、問題が発生しました。特に、異なるコーダーからのモジュールにパッチを適用する場合。また、多くの回答者が大文字と小文字を区別しないことの意味を理解していないようです。文字a〜zのみが影響を受けます。これらはASCII文字のシーケンシャルサブセットです。3バイトまたは4バイトのマシンコードにより、コンパイラはこの範囲の文字の大文字と小文字を区別しません。アンダーバーや数字などは変更されません。 。他の言語や文字セットに関するポイントは、この説明には当てはまりません。コンパイラまたはインタラプタは、ASCII）であることを基に、コンパイル時に分析のために文字を一時的に変換するか、変換しないようにコーディングされます。 =かどうか。
K＆Rが犯した間違いを繰り返して出てきたPythonのような新しい言語にショックを受けました。はい、合計RAM）の環境で半ダースバイトを節約しました。 =コンパイラ、ソース、およびオブジェクトコードの場合は1000バイトでした。それは当時でした。メモリは問題ではありません。今では、意味のある理由もなく、Pythonの予約ワードでさえ大文字と小文字が区別されます！ 「Print」の「For」を変数名や関数名として使用する必要はないと思いますが、その可能性は、各識別子の正確なケースでインタラプタに満足するために費やされる時間のコストによって維持されています。おもう。
大文字と小文字の区別をサポートするためにこれまで読んだ中で最も近いものは、ハッシュに関するコメントです。しかし、細部に注意を払って処理できるこれらのまれなコーディングイベントは、大文字と小文字を区別するコードを作成するためにコーダーが使用しなければならない無意味な精査の価値がないようです。問題の2つの見方。悪いコーディングを奨励し、コードに罠を仕掛け、より大きな概念からそらすには特別な注意が必要です。もう1つには欠点がなく、高水準言語で問題なく動作し、害がなければ柔軟性があります。私には、VHSのさらに別のケースがベータ版に勝ったように見えます。ここでは私の2セントの価値があります。
大文字と小文字を区別する言語を使用することで、人々は貧弱なコードを書くようになります。
Const SHOESIZE = 9
Class ShoeSize
ShoeSize.shoesize = SHOESIZE
call shoeSize(ShoeSize);
function shoeSize(SHOEsize)
{
int ShoeSIZE = 10
return ShoeSize
}
ええと。さまざまな目的で「ShoeSize」よりも優れた変数名を考えることはできませんか？使用できる単語は数十億ありますが、代わりにShoeSizeを使い続けることを選択しますか？
ここの多くの人々は、大文字のいくつかの形式が同じことを参照するのは悪いことだと言っています。
person
perSoN
PERSON
本当に悪いのは、これらすべてがコード内の異なるオブジェクトを参照している場合です。変数person、perSoN、およびPERSONがすべて異なるものを参照している場合は、問題が発生します。
一般的なコーディング標準では、Personはクラス、personは変数名、PERSONは定数になります。大文字と小文字が異なる同じ単語を使用して、関連しているがわずかに異なるものを意味することが役立つことがよくあります。
それで、あなたのビジネスにロバートと呼ばれる3人のスタッフがいるとしたら、彼らをロバート、ロバート、ロバートと呼びますか？そして、あなたが何を意味するのかを正確に知るために人々に頼りますか？
電子メールシステムで大文字と小文字が区別される場合は、Robert @ widgets.com、robert @ widgets.com、ROBERT @ widgets.comなどの電子メールアドレスを提供しますか？
個人データの不正な侵害の可能性は非常に大きいでしょう。解雇されようとしている不満を持つ従業員にデータベースのrootパスワードを送信したかどうかは言うまでもありません。
それらをボブ、ロビー、ロバートと呼ぶ方がよいでしょう。彼らの姓が例えばであるならば、彼らをロバートA、ロバートBおよびロバートCと呼ぶほうがよい。アーサー、バンクス、クラーク
本当に-なぜ地球上で、人々が非常に警戒していることに依存する、間違いや混乱を招く命名規則があるのですか？あなたはあなたの語彙の言葉がとても不足していますか？
そして、おそらく便利なトリック「MyClass myClass」に言及している人については、なぜ、なぜですか？使用されているメソッドがクラスメソッドなのかインスタンスメソッドなのかが一目でわかりにくくなっています。
さらに、コードを読んでいる次の人に、クラスの特定のインスタンスについて詳しく伝える機会を失いました。
例えば。
顧客PreviousCustomer
顧客NewCustomer
顧客CorporateCustomer
インスタンス名は、それが基づいているクラスだけでなく、理想的には同僚に伝える必要があります。
多くの人がemployeeSocailSecurityNumberをemployee_social_security_numberと同じくらい読みやすく、それより短いと感じているからです。
例を挙げれば、学習は常に簡単なので、次のようになります。
C＃（大文字と小文字を区別しますが、大文字と小文字を区別しないVB.NETから使用できます）：
CONSTANT_NAME
IInterfaceName // Uses I prefix in all case sensitive and insensitive languages
ClassName // Readable in both case sensitive and insensitive languages
_classMember // sometimes m_classMember or just classMember
DoSomething(someParam) // Method with action name, params can be _someParam
PropertyName // Same style in case sensitive and insensitive languages
localVariable // Never using prefix
JavaとJSはC＃に似たスタイルを使用しますが、メソッド/関数/イベントは変数doSomething、onEventのように宣言されます。
ObjectPascal（DelphiとLazarus/FPCは、ADAやVB.NETのように、大文字と小文字を区別しません）
CConstantName // One can use Def or no prefix, not a standard
IInterfaceName
TClassName // Non-atomic types/classes have T prefix e.g. TStructRecordName
PSomePointer // Pointers have types, safer low level stuff
FClassFieldMember // F means Field member similar to m
DoSomething(Parameter) // Older code uses prefix A for parameters instead
PropertyName
LLocalVariable // Older code uses prefix for parameters not local vars
タイプごとにOneCaseとプレフィックスのみを使用することは、すべての言語で意味があります。接頭辞なしで始まった言語でさえ、大文字と小文字を区別せず、代わりに接頭辞を使用するインターフェースのような新しい構造を持っています。
したがって、言語で大文字と小文字が区別されるかどうかはそれほど重要ではありません。大文字と小文字を区別する言語に新しい概念が追加されました。大文字と小文字を区別する言語では、大文字と小文字だけでは表現できず、接頭辞を使用する必要がありました。
大文字と小文字を区別する言語ではプレフィックスの使用が開始されたため、同じ識別子名someIdentifier SomeIdentifier SOME_IDENTIFIER、ISomeIdentifierで大文字と小文字を区別するのをやめ、意味のある場合はプレフィックスを使用するのが妥当です。
この問題を考えてみましょう。何かと呼ばれるクラスメンバー、何かと呼ばれるメソッド/関数パラメーター、および何かと呼ばれるローカル変数があります。これらを簡単に区別するために、どのような場合の規則を使用できますか？どこでも最もConsistentCaseStyleを使用して、プレフィックスを追加する方が簡単ではありませんか？
大文字と小文字を区別しない言語のファンは、コードの品質に関心があり、1つのスタイルだけが必要です。 1つのライブラリの記述が不十分であり、厳密なスタイルを使用している一方で、ライブラリにスタイルがないか、コードが不十分であるという事実を受け入れる場合があります。
大文字と小文字を区別する言語と区別しない言語はどちらも厳格な規律が必要です。どこにでも1つのスタイルしかない方が理にかなっています。 StrictCaseのみを使用し、どこでも1つのスタイルとプレフィックスを使用する言語があれば、より良いでしょう。
貧弱なCコードがたくさんあり、大文字と小文字を区別しても読みやすくならず、何もできません。大文字と小文字を区別しない言語では、ライブラリを書き直すことなく、コードに適切なスタイルを適用できます。まだ存在しないStrictCase言語では、すべてのコードはまともな品質になります:)
また、すべてのクラス、変数、関数、およびメソッドに（愚かにも）1文字（「a」と「b」と「c」）を使用することもできます。
しかし、[〜＃〜]なぜ[〜＃〜]したいですか？
意味のある名前を使用してくださいではなく：
function a(a)
{
int a = a.a;
return a
}
人々は物事を真剣に考えすぎているからです。
大文字と小文字を区別しない場合は、大文字と小文字を区別せず、型と変数の名前空間を分離することで最適に機能します。この意味は：
クラスを「
TextureImage」として宣言し、それを「textureImage」として使用しようとすると、IDEは自動修正できます。これにより、利点が得られます。識別子を宣言するか、アンダースコアを使用しない限り、Shiftキーを押す必要はありません。Javaおよび他のいくつかの言語と同様に、「
MyClass myClass」と入力することは完全に有効です。IDEであり、コンパイラは問題なく区別できるはずです。型の使用と変数の使用の間。
さらに、大文字と小文字を区別しないことで、「o」と「O」が異なるオブジェクトを参照しないことが保証されます。一般的な引数は次のとおりです。
"
sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => そして、誰かがプログラミングチームに参加することは_決して_許可されないので、これはストローマンの議論です。たとえ彼らが参加できたとしても、大文字と小文字の区別は問題よりも解決策です。使用する大文字と小文字の組み合わせを覚えておく必要はありません。"大文字と小文字を区別しないことを簡単に国際化することはできません！"; => プログラミング言語の95％以上は、非常に正当な理由で英語で書かれています。競合する文字エンコードはなく、地球上のキーボードの大部分は英語ベースです（部分的または全体的に）。ユニコード識別子のサポートはおそらく21世紀に誰もが思いついた最も愚かな考えです。ユニコード文字の大部分はフリッキンの目に見えないサレージであるため、コードの読み取りはgoogle translateを使用せずに十分に困難であり、コードの記述はコピーアンドペーストを必要とせずに十分に困難です識別子または文字マップを使用します。
"ただし、大文字と小文字を区別する言語には、より多くの識別子があります！"; => いいえ、文法的にオーバーロードされた識別子がありますが、これはかなり悪いです。
大文字と小文字を区別しない言語は使用しませんが、この種のことを真剣に考えれば、その利点は明白です。
MyClass myClass;大文字と小文字を区別しないコンパイラでは不可能です。
または、賢くて実際に2つの異なる単語を使用することもできます...これは、実際に何をしようとしているのかをよりよく示しています。
MyClass myCarDesign;
ええと。
合理的な答えは、言語の設計者が、将来について考えることで言語が理解しやすくなると考えたということかもしれません:)
単語の区切りが重要でない場合、なぜ単語の間にスペースを入れるのですか？したがって、名前の単語間の下線は読みやすさを向上させると思います。また、適切な文字を大文字にする小文字が最も読みやすくなっています。最後に、すべての単語を口コミで伝えることができれば、確かにはるかに簡単です。「大文字のC小文字」ではなく、「企業のアンダースコアの顧客」です。アンダースコアの大文字の小文字を使用します。 -前者は「頭の中で」話すことができますが、後者はできません-大文字と小文字の区別に満足している人は、これらの大文字と小文字を区別する名前を脳内でどのように扱うのだろうか-私は本当に苦労しています。したがって、大文字と小文字の区別はまったく役に立たないと思います。私の意見では、COBOLからのレトロゲードステップです。
大文字と小文字の区別が重要であることにほとんどの人が同意しているようですが、私も同意します。
ただし、正しい大文字と小文字を入力する必要がある場合は煩わしいことがあるため、IDEを使用すると間違った大文字と小文字を入力できるはずですが、オートコンプリートショートカットを押すと、大文字と小文字を区別しないマッチングを実行します。これにより、両方の長所が得られます。
言語で大文字と小文字が区別されるもう1つの理由があります。 IDはハッシュテーブルに格納される場合があり、ハッシュテーブルは、ケースごとに異なるハッシュを提供するハッシュ関数に依存しています。また、ハッシュ関数を実行する前に、すべてのIDをすべて上位またはすべて下位に変換するのは便利ではない場合があります。自分のコンパイラを書いているときにこの問題に遭遇しました。私の言語を大文字と小文字を区別するものとして宣言する方がはるかに簡単（怠惰）でした。