language-design - 多くの言語で大文字と小文字が区別されるのはなぜですか?

Question

多くの言語で大文字と小文字が区別されるのはなぜですか?

単に継承の問題ですか？C は C であるため C++ は大文字と小文字を区別し、Java は C++ であるため大文字と小文字を区別します。それとも、もっと現実的な理由があるのでしょうか?

score 66 · Accepted Answer

「その言語の作者がそのほうがいいと思ったから」よりも良い答えは得られないと思います。個人的には、彼らは正しいと思います。これらの行を同じソースファイル内のどこかに見つけるのは嫌です (同じオブジェクトとメソッドを参照します)...

SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();

これを見て喜ぶ人はいないと思いますが…

score 64 · Accepted Answer

Unix。

Unixは大文字と小文字を区別し、Unixで使用するために開発された非常に多くのプログラミング言語は大文字と小文字を区別していました。

コンピュータは寛容ではありません-大文字は小文字と同じものではなく、まったく異なります。そして、処理サイクルやRAMなどが高価だった頃は、コンパイラやコンピュータを「寛容」にする努力をする価値はないと考えられていました。人々はただ物事を機能させようとしていました。

Visual Basicのようなものが登場するまで、大文字と小文字を区別しないことが実際には役に立たなかったことに注目してください。企業が大衆をプログラムすることは彼らの収益にとって良いことであるという概念に投資し始めたら（つまり、Microsoftはより多くのお金を稼ぎます。 Windowsにはもっと多くのプログラムがあります）言語はより親しみやすく、より寛容になり始めました。

score 36 · Accepted Answer

考慮すべき興味深い点の 1 つは、英語でも大文字と小文字が区別されることです。(これはほとんどの自然言語に当てはまると思いますが、すべてに当てはまるとは限りません。)

大きな違いがあります (とにかく、レディングの町の近くに住んでいます)。

私は読書が好きです。

と

私は読書が好きです。

同様に、多くの人が間違って大文字を使用しており、通常はその意味を理解できますが、そのような書き方が正しいと見なされるわけではありません。私はこの種のことに関してはうるさいですが、もちろん、自分ですべてを正しく理解しているとは言えません。それがプログラミング言語の大文字と小文字の区別の継承の一部であるかどうかはわかりませんが、そうかもしれません。

プログラミング言語で大文字と小文字を区別する明確な利点の 1 つは、テキストが文化的にも区別されなくなることです。ソースファイルにどのテキストエンコーディングが使用されているかをコンパイラに時々詳しく説明しなければならないのは十分に悪いことです-それがどのカルチャにあるかを指定しなければならないのはさらに悪いことです:(

score 28 · Accepted Answer

これは、開発者と言語構文仕様の両方にとって、実際には非常に実用的です。小文字/大文字の区別により、識別子の命名に多くの表現力が追加されます。

言語構文の観点から、特定の識別子を強制的に小文字または大文字で開始することができます (たとえば、Java クラス名)。これにより解析が容易になり、構文をきれいに保つのに役立ちます。

開発者の観点から見ると、これにより多数の便利なコーディング規則が可能になり、コードがより明確で理解しやすくなります。

score 24 · Accepted Answer

大文字と小文字の折り畳みは、英語 (および 128 未満のすべての文字) でのみ簡単です。ドイツ語のsz または「sharp s」(ß)には、ISO 8859-1 文字セットに大文字のバリエーションがありません。約10 年の議論の後、Unicode で 1 つだけ受け取りました(そして今、すべてのフォントを更新する必要があります...)。漢字とひらがなは小文字すら知らない。

この混乱を避けるために、この Unicode の時代であっても、大文字と小文字の折り畳みとUnicode 識別子を許可することは賢明ではありません。

score 24 · Accepted Answer

私の推測では、大文字と小文字を区別すると名前空間が拡大します。のような素敵なトリック

MyClass myClass;

大文字と小文字を区別しないコンパイラでは不可能です。

score 15 · Accepted Answer

ExpertSexChange

これは、回答を読むためにお金を払わなければならない Stack Overflow のライバルだと思います。うーん...大文字と小文字を区別しないため、サイトの名前の意味があいまいです。

これは、言語が大文字と小文字を区別する正当な理由です。曖昧さが少ない！プログラマーにとってあいまいさは厄介なものと見なされます。

score 15 · Accepted Answer

解析とコンパイルが非常に高価で、一晩中かかっていた時代には、大文字と小文字を区別する必要がなければ、コンパイラにとって有利でした。

大文字と小文字のみが一意である識別子が存在するようになると、元に戻すことは非常に困難になりました。多くの開発者はそれを気に入っており、元に戻したいという大きな願望はないようです。

score 11 · Accepted Answer

大文字と小文字の区別により、命名規則を使用することで言語の読みやすさが向上します。あなたは書くことができません

Person person = new Person("Bill");

コンパイラがクラス名と変数名を区別できないため、言語が大文字と小文字を区別しない場合。

また、Person、Person、PersonN、PeRsOn、および PERSON がすべて同等のトークンであると、頭痛の種になります。:)

score 9 · Accepted Answer

iの大文字の形は何ですか? 私(U+0049) またはİ (U+0130)?

大文字と小文字はロケールに依存します。

score 8 · Accepted Answer

彼らはカエルの箱のように愚かなので、まさにこのスレッドの反対の視点のために与えられた理由のために（私はそれが何であるかを尋ねるつもりはありません。木のための木材とそのすべて）。

FOOBAR = FooBar = foobarの場合、規則を選択できます。他のコーダーは、好みを共有しているかどうかに関係なく、同じことを行うことができます。混乱はありません。

また、大文字が異なっていても、同じファイルに同じ名前の定数、関数、変数が含まれている天才のストロークから逃れることはできません。繰り返しますが、混乱はありません。

あなたはあなたの変数のウェブサイトを呼び、彼らは彼らのウェブサイトを呼びます、そしてどのシステムが混乱しますか？スキャンしているときも、簡単にキャッチすることはできません。

ルックアップに関しては、ルックアップする前に名前を小文字に変換するのは本当にはるかに多くの処理ですか？独自の時期尚早な最適化を行うことは1つのことであり、選択した言語の開発者にそれを期待することは、まったく別のレベルの要点を見逃すことです。

...それでも、大文字と小文字を区別するというこれらの回答はすべて、混乱を減らします。はぁ

score 8 · Accepted Answer

多くの（プログラミングではない）言語（たとえば、ローマ字を使用するヨーロッパ言語）では大文字と小文字が区別されるため、これらの言語のネイティブスピーカーが大文字と小文字を区別するのは自然なことです。

プログラミング言語では大文字と小文字が区別されないという考え自体が、初期世代のハードウェア（5ビットの文字コードを使用するプレコンピューターテレタイプマシンを含む）の制限から生じる歴史的なアーティファクトです。

大文字と小文字を区別しない言語を主張する人々は、区別できないはずです

IAmNowHere

から

IAmNowhere

（それは冗談です！ ;-)

score 4 · Accepted Answer

CAPS を持っていない場合、どのように叫ぶのですか?! ああ！

あなたは表現力豊かでなければなりません。しかし、正直なところ、世界中のすべての人々の中で、プログラミングロジックを扱っている人は、違いは実際には違いであると最初に主張するでしょう。

score 4 · Accepted Answer

大文字と小文字を区別しない言語である Common Lisp もありますが、多くの人は大文字と小文字を区別しないと誤解しています。リスナーに入力すると、処理用(car x)に変わります。(CAR X)小文字の名前でシンボルを定義することは可能ですが、|lower-case-symbol|. したがって、またはすべてを入力し(car x)ても同じように機能します(CAR X)。(Car X)

(Franz Lisp はある時点で、彼らが「モダンな」大文字化と呼ぶものを導入していました。この場合、Listener は大文字と小文字を折り畳まず、CL キーワードは小文字になります。私はそこで何が起こったのかを知るのに十分に従ったことはありませんでした。)

score 4 · Accepted Answer

このスレッド全体を読みました。大文字と小文字の区別に価値を見いだしたと報告する人は、真の高級言語 (定義上、大文字と小文字を区別しない) でプログラミングしたことがないと信じなければなりません。K&R は、C が中間レベルであることを認めています。Pascal、Delphi、Lazarus、ADA などでプログラミングした後、非常に読みやすいコードは簡単に記述でき、大文字と小文字を区別する簡潔な構造にこだわらずにすぐに実行できることがわかります。結局のところ、読みやすさはこのテーマの最初で最後の言葉です。コードはコンピュータではなく、人間のために書かれています。大文字と小文字を区別しないコードで問題なくデバッグできます。中間レベルの言語に移行すると、大文字と小文字を区別するメリットがないことがわかります。ただし、大文字と小文字の区別をデバッグするのにかなりの時間が費やされ、問題が発生しました。特に、異なるコーダーからのモジュールを一緒にパッチする場合。また、多くの回答者は、大文字と小文字を区別しないという意味を理解していないようです。文字 a ～ z のみが影響を受けます。これらは、ASCII 文字の連続したサブセットです。3 バイトまたは 4 バイトのマシンコードにより、コンパイラはこの範囲の文字の大文字と小文字を区別しなくなります。アンダーバー、数字、またはその他のものは変更されません。他の言語と文字セットに関するポイントは、この説明には当てはまりません。コンパイラまたはインタラプタは、ASCII であるかどうかに基づいて、コンパイル時に分析のために文字を一時的に変換するか変換しないようにコーディングされます。これらは、ASCII 文字の連続したサブセットです。3 バイトまたは 4 バイトのマシンコードにより、コンパイラはこの範囲の文字の大文字と小文字を区別しなくなります。アンダーバー、数字、またはその他のものは変更されません。他の言語と文字セットに関するポイントは、この説明には当てはまりません。コンパイラまたはインタラプタは、ASCII であるかどうかに基づいて、コンパイル時に分析のために文字を一時的に変換するか変換しないようにコーディングされます。これらは、ASCII 文字の連続したサブセットです。3 バイトまたは 4 バイトのマシンコードにより、コンパイラはこの範囲の文字の大文字と小文字を区別しなくなります。アンダーバー、数字、またはその他のものは変更されません。他の言語と文字セットに関するポイントは、この説明には当てはまりません。コンパイラまたはインタラプタは、ASCII であるかどうかに基づいて、コンパイル時に分析のために文字を一時的に変換するか変換しないようにコーディングされます。

K&R が犯した過ちを繰り返している Python のような新しい言語に私はショックを受けています。はい、コンパイラ、ソース、およびオブジェクトコードの合計 RAM が 1000 バイトである環境で、半ダースバイトを節約しました。それはその時でした。現在、メモリは問題ありません。さて、理にかなった理由もなく、Python の予約語でさえ大文字と小文字が区別されます! 「Print」の「For」を変数名や関数名として使う必要はないと思います。しかし、その可能性は、各識別子の正確な大文字と小文字についてインタラプタと競合するのに費やされた時間のコストによって保持されています。悪い取引だと思います。

大文字と小文字の区別をサポートするためにこれまでに読んだ中で最も近いものは、ハッシュに関するコメントです。しかし、細部に細心の注意を払って処理できるこれらのまれなコーディングイベントは、大文字と小文字を区別するコードを記述するためにコーダーが使用しなければならない無意味な精査に値するものではないようです。問題の 2 つのビュー。悪いコーディングを助長し、コードにトラップを設定し、より大きな概念から逸れるように特別な注意を払う必要があります。もう 1 つはマイナス面がなく、高水準言語で問題なく動作し、害がなければ柔軟性を許容します。私には、VHS が BETA に勝ったまた別の事例があるように見えます。ここにあるのは私の 2 セントの価値だけです。

score 4 · Accepted Answer

文字の大文字は普遍的な概念ではありません。Java は Unicode を使用するため、大文字と小文字を区別しない Java が必要な場合、コンパイルされたロケールによってプログラムの意味が変わる可能性があります。

ほとんどの言語では、整数リテラルの途中にドットやコンマ (またはアポストロフィやスペース) を配置することはできません。おそらく、これもロケールに依存するためです。

score 4 · Accepted Answer

.NET Framework Developer's Guide Capitalization Conventionsから、大文字と小文字の区別:

大文字と小文字のガイドラインは、識別子を読みやすく、認識しやすくするためだけに存在します。ライブラリ要素間の名前の衝突を回避する手段として、大文字と小文字を区別することはできません。

すべてのプログラミング言語で大文字と小文字が区別されるとは限りません。ではない。大文字と小文字だけで名前を区別することはできません。

score 3 · Accepted Answer

大文字と小文字を区別する言語を使用することで、人々は貧弱なコードを書くようになります。

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize)
{
   int ShoeSIZE = 10
   return ShoeSize
}

ええと。さまざまな目的で「ShoeSize」よりも優れた変数名を思いつくことはできませんか？使用できる単語は数十億ありますが、代わりにShoeSizeを使い続けることを選択しますか？

score 3 · Accepted Answer

ここにいる多くの人は、複数の形式の大文字化が同じものを参照するのは良くないと言っています。例えば:

person
perSoN
PERSON

本当に悪いのは、これらすべてがコード内の異なるオブジェクトを参照している場合です。変数 person、perSoN、および PERSON がすべて異なるものを参照している場合、問題が発生します。

score 3 · Accepted Answer

私が見た大文字と小文字の区別をサポートするすべての例は、不適切で説明のつかないコードを書きたいという欲求に基づいています。たとえば、"date" 対 "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

驚くべきことに、これは機密性の高い VB.Net コードでは完全に有効なケースです。大文字と小文字を区別すると、優れたプログラミング手法にさらに著しく従わなくなるという考えは、賛成ではなく反対の議論です。

score 3 · Accepted Answer

大文字と小文字の区別は、大文字と小文字の一貫性にはあまり役立ちません。

Foo.Bar  
foo.Bar  
fOO.bAR

エディターによって簡単に自動的に修正できる、大文字と小文字を区別しない言語。大文字と小文字を区別する言語では、合法である可能性があるため、それを修正するのは困難です。エディターは最初に foo.Bar と fOO.bAR が存在するかどうかを確認する必要があり、変数の宣言を忘れるのではなく、大文字と小文字を間違えて入力したことを推測する必要があります (Foo は fOO とは異なるため)。

score 1 · Accepted Answer

学習は例によって常に簡単になるので、ここに行きます：

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 つのスタイルだけが必要です。あるライブラリの記述が不十分で厳密なスタイルを使用しているにもかかわらず、そのライブラリにはスタイルがないか貧弱なコードであるという事実を受け入れる場合があります。

大文字と小文字を区別する言語と区別しない言語の両方に厳格な規律が必要です。StrictCase のみを使用し、すべての場所で 1 つのスタイルと接頭辞を使用する言語があればより良いでしょう。

貧弱な C コードがたくさんあります。大文字と小文字が区別されると読みにくくなり、何もできません。大文字と小文字を区別しない言語では、ライブラリを書き直さずにコードに適切なスタイルを適用できます。まだ存在しない StrictCase 言語では、すべてのコードがまともな品質になります:)

score 1 · Accepted Answer

また、(愚かなことに) すべてのクラス、変数、関数、およびメソッドに単一文字 ("a" と "b" と "c") を使用することもできます。

しかし、なぜあなたはしたいのですか？

次のものではなく、意味のある名前を使用してください。

function a(a)
{
    int a = a.a;
    return a
}

score 1 · Accepted Answer

多くの人は、employeeSocailSecurityNumber が employee_social_security_number と同じくらい読みやすく、短いと感じているためです。

score 1 · Accepted Answer

典型的なコーディング基準では、Person はクラス、person は変数名、PERSON は定数です。大文字と小文字が異なる同じ単語を使用して、関連しているがわずかに異なる何かを意味することがよくあります。

では、あなたのビジネスに 3 人のスタッフが全員ロバートと呼ばれている場合、それらをロバート、ロバート、ロバートと呼びますか? そして、あなたがどちらを意味したかを正確に知るために人々に頼りますか？

電子メールシステムで大文字と小文字が区別される場合、Robert@widgets.com、robert@widgets.com、ROBERT@widgets.com などの電子メールアドレスを提供しますか?

個人データが不正に侵害される可能性は非常に高くなります。解雇されようとしている不満を抱いた従業員にデータベースのルートパスワードを送信したかどうかは言うまでもありません。

ボブ、ロビー、ロバートと呼んだほうがいいでしょう。彼らの苗字が Arthur、Banks、Clarke の場合は、Robert A、Robert B、Robert C と呼んだほうがよいでしょう。

本当に - 一体なぜ、間違いや混乱を招き、非常に注意深い人々に依存する命名規則があるのでしょうか? 語彙の単語がそんなに不足していませんか？

そして、おそらく便利なトリック「MyClass myClass」について言及している人については、なぜ、なぜ、なぜですか? メソッドがクラスメソッドなのかインスタンスメソッドなのか一目で分かりにくくしている。

さらに、コードを読んでいる次の人に、クラスの特定のインスタンスについて詳しく伝える機会を失いました。

例えば。

お客様前のお客様

顧客新規顧客

顧客企業顧客

インスタンス名は、理想的には、それが基づいているクラス以上のものを同僚に伝える必要があります!

score 0 · Accepted Answer

MyClass myClass; 大文字と小文字を区別しないコンパイラでは不可能です。

または、賢くて実際に2つの異なる単語を使用することもできます...これは、実際に何をしようとしているのかをよりよく示しています。

MyClass myCarDesign;

ええと。

score 0 · Accepted Answer

言語で大文字と小文字が区別される別の理由があります。ID はハッシュテーブルに格納される場合があり、ハッシュテーブルは、大文字と小文字が異なる場合に異なるハッシュを提供するハッシュ関数に依存します。また、ハッシュ関数を実行する前に、すべての ID をすべて上位またはすべて下位に変換するのは便利ではない場合があります。独自のコンパイラを作成しているときに、この問題に遭遇しました。自分の言語を大文字と小文字を区別すると宣言する方がはるかに簡単 (怠惰) でした。

score 0 · Accepted Answer

単語の区切りが重要でない場合、なぜ単語の間にスペースを入れるのでしょうか? したがって、名前の単語間の下線は読みやすさを向上させると思います。また、適切な文字の大文字化を使用した小文字が読みやすいです。最後に、「Capital C Lower Case orporate Underscore Capital C Lower Case ustome r」ではなく、「Corporate Underscore Customer」という口コミですべての単語を伝えることができれば、はるかに簡単です。- 前者は「頭の中で」話すことができ、後者は話せません - 大文字と小文字の区別に満足している人は、頭の中でこれらの大文字と小文字を区別する名前をどのように処理するのだろうか - 私は本当に苦労しています. したがって、大文字と小文字の区別はまったく役に立たないと思います-私の意見では、COBOLからの逆行です。

score 0 · Accepted Answer

合理的な答えは、言語の設計者が、将来のことを考えて言語を理解しやすくするだろうと考えたということかもしれません:)

score -1 · Accepted Answer

大文字と小文字の区別が重要であることにほとんどの人が同意しているように見えますが、私も同意します。

ただし、大文字と小文字を正しく入力しなければならない場合は煩わしいので、IDE では大文字と小文字を間違えて入力できるようにする必要がありますが、オートコンプリートショートカットを押すと、大文字と小文字を区別しないマッチングが行われるはずです。これにより、両方の長所が得られます。

language-design - 多くの言語で大文字と小文字が区別されるのはなぜですか?

31 に答える 31

Related

Reference