言語の大文字と小文字を区別しないキーワード[非公開]

カスタムスクリプト言語を記述しようとしています。大文字と小文字を区別しないキーワードを提供することで言語を容認する提案がありました。

私は個人的にこのアイデアが好きではありませんが、エンドユーザーを幸せにするだろうと言っている私のチームの人はほとんどいません！FORTRAN、BASIC、SQLなどの言語の例では、大文字と小文字が区別されないことを示しています。

これはいい考えですか？

エンドユーザーが誰であるか自問してください。CやJavscriptのプログラミング経験がある人、またはUnixのIT経験を持つ人が作成することを意図している場合、大文字小文字の区別はおそらく正しいことです。ユーザーがそれを期待しているからです。しかし、ほとんどのエンドユーザー、パワーユーザーであっても、これは混乱を招くでしょう。

VB / VBA / VBScriptは大文字と小文字を区別しません。これは、プログラマーでない人でも簡単に言語を理解できるようにするために行われた決定です。スクリプトではなく、多くのユーザーが取得するExcelの式では、大文字と小文字は区別されません。ほとんどのケースの選択肢を書いて、テキストの外観多かれ少なかれプロと研磨作ることができますが、場合には、自己が変更されませんセマンティック言葉の意味を。だから、開発者以外は大文字と小文字を区別するスクリプト言語に混同されると信じています。

繰り返しますが、これは技術的な選択ではありません。これは、対象読者をよく知っている人々が行う必要がある製品管理の選択です。

実装がどれほど簡単か難しいかではなく、提示したいユーザーエクスペリエンスに基づいて決定する必要があります。

ユーザーが大文字と小文字を区別しにくくする場合は、それを実装する必要があります。

ポイントとして、SQLは大文字と小文字を区別しません。これにより、インタラクティブな設定で非常に使いやすくなります。

これを見てする別の方法があるが、これまでとの違いになりますkeywordし、Keywordあなたの言語で、この差は、ユーザにとって意味でしょうか？スクリプト言語の場合、答えは「いいえ」です。

プログラミング言語は、大文字と小文字を区別する期間にする必要があります。人々はこれに非常に簡単に調整できます。ほとんど小文字で作業し、既存のAPIで大文字と小文字が混在する識別子またはすべて大文字の識別子に注意する必要があります。

言語の大文字と小文字を区別しないようにすることはかつて明白に思えました。これは、すべてのコンピューティングシステムとそのI / Oデバイス（キーボード、プリンター、ディスプレイデバイス）で小文字が利用可能でなかったためです。プログラミング言語の実装では、大文字で記述されたプログラムのみを表示または印刷できるため、受け入れなければなりませんでした。そして、そのために彼らは、上ケースを受け入れるようにするので、ケース・小文字を区別しないでなければならなかったと下部ケースを拒否すると同時に手段で大文字と小文字を区別すること。小文字はプログラマーが望んでいたものでしたが、常に持つことはできませんでした。大文字で叫んだプログラムを実際に使用したい人はいませんでした。それは単なるハードウェアの制限でした。

しばらくの間、端末でケースの折りたたみを行うことさえ一般的でした。端末が大文字しか表示できないが、大文字と小文字をサポートするコンピューティングシステムにログインする必要がある場合、端末は小文字を大文字に変換します。これはずっと前だと思いますか？「Apple IIのように、Apple II Plusには小文字の機能はありませんでした。」（http://en.wikipedia.org/wiki/Apple_II_Plus）初期のAppleコンピューターのユーザーが大文字と小文字が混在するBBSにダイヤルインすると、ターミナルエミュレーター（またはホスト）はすべてを大文字に変換する必要がありました。当時は、すべて大文字で書かれたメッセージが掲示板で一般的でした。この機能は、LinuxカーネルなどのUnixライクなオペレーティングシステムで引き続き使用されています。たとえばstty olcuc、シェルプロンプトでを入力します。Unix ttyのライン制御では、出力で小文字を大文字にマッピングでき、入力で大文字を小文字にマッピングできます。これにより、小文字を持たない端末で、小文字のプログラミング言語で作業できます。

大文字と小文字を区別しないことは、過去のコンピューター時代の時代遅れの概念であり、国際化されたコンピューティングの現代世界ではあまりうまく機能しません。それを他の言語に拡張しますか？フランス語はどうですか：Èとèは同等だと思いますか？それとも日本人？ファイルとふぁいるが同じ識別子であるように、ひらがなとカタカナは単なるケースであると考えていますか？このような愚行をサポートすると、字句アナライザーが大幅に複雑になり、Unicodeスペース全体の大文字小文字の等価マップが必要になります。

数学では大文字と小文字が区別されることに注意してください。たとえば、大文字のシグマは合計を表し、小文字のシグマは標準偏差などの別の何かを表します。これは、同じ式で問題なく作成できます。（プログラミング言語はΣとσを同等にしますか？）

英語の正書法は敏感です。たとえば、多くの固有名詞は、通常の名詞またはその他の品詞に対応します。「may」は動詞ですが、「May」は月、または女性の名前です。さらに、頭字語または略語が小文字で書かれている場合、混乱を招く可能性があります。SATは学力適性検査の略で、「sat」は「sit」の過去分詞です。知的な人々は細部に注意を払い、適切に大文字を使います。

基本的に、1985年以降に作成された大文字と小文字を区別しない新しいプログラミング言語は、電子メールや投稿を2回目の発想なしで発言する人のためのものです。

あなたの言語が別の言語のコードを翻訳するためのコード生成ターゲットとして使用され、その他の言語が大文字と小文字を区別する場合はどうなりますか？どうにかしてすべての名前を変換して区別をキャプチャする必要があります。（つまり、これは技術的な決定ではなく、対象となる視聴者の感情的な好みの問題だけであると断言するのはばかげています。）

ファイルが別のオペレーティングシステムからインポートされるときに、Windowsでのケース処理によって引き起こされる迷惑な問題を見てください。これは技術的な問題です。大文字と小文字を区別するファイルシステムには、大文字と小文字を区別しないファイルシステムにはない外部データに関する問題があります。

Common Lispは理想的なアプローチを採用しています。シンボル名は大文字と小文字が区別されますが、トークンが読み取られると、大文字に変換されます。この手段そのトークンfoo、fOO、FOOおよびFooすべての意味同じ記号：名前文字列として保存されているシンボル"FOO"。さらに、この動作はデフォルトの読み取りテーブル設定にすぎません。読者は、大文字を小文字に折り畳んだり、大文字を反転したり、保存したりすることができます。最後の2つの選択により、大文字と小文字が区別される方言が生成されます。これにより、ユーザーは最大限の柔軟性を得ることができます。

実際の決定要因は、同じ名前の複数のものをどのくらいの頻度で作成するかです。という名前の列が必要になることはあまりないため、SQLでは大文字と小文字を区別しませんSELECT。Javaでは他のすべての行がのようObject object = new Object()に見えるため、同じ名前でクラス、インスタンス、およびコンストラクターを参照するため、面倒です。

つまり、大文字と小文字の区別は名前のオーバーロードに最も役立ち、オーバーロードは大規模で複雑なプロジェクトで主に役立ちます。スクリプト言語など、よりまれに使用する場合は、大文字と小文字を区別しないため、プログラミングがはるかに簡単になります。

識別子が大文字と小文字を区別しないだけでなく、空白も区別しないルール言語を一度作成しました。また、同じ識別子を参照するエイリアスを作成することもできました。たとえば、ProgrammersStackExchange、プログラマースタックエクスチェンジ、およびPSEはすべて、まったく同じシンボルに解決され、互換的に使用できます。

ドメインには同じものを参照する非常によく知られた多くの方法があり、名前の競合はまれだったため、非常にうまく機能した私のドメインにとって。ある名前を使用してクエリを入力し、その結果に別の名前を使用しても驚くことはありません。言語サポートにより、ドメインとプログラミング言語間の翻訳が非常に簡単になりました。ただし、変数へのすべての参照を見つけるなど、特定のタスクが難しくなりました。ありがたいことに、私の場合、このような状況はめったに起こらないか、支援するツールサポートを構築するのはかなり簡単でしたが、自分の状況を考慮する必要があります。

スクリプト言語で大文字と小文字が区別されると仮定します。変数名またはキーワードに間違った大文字と小文字を使用してタイプミスをしたかどうかをユーザーに知らせるコンパイラまたは構文チェッカーを作成しますか？そうでない場合、言語の大文字と小文字を区別しないようにするための非常に強力な議論になります。

オンザフライで変数を宣言できますか？もしそうなら、私は大文字と小文字を区別しないと主張します。

ATypo = 42; 

とは対照的に

Atypo = 42; 

デバッグ時間を不必要に要求するのは、2つのステートメントを同等にすることで作業が楽になるからです。

FORTRAN、BASIC、SQLなどの言語の例では、大文字と小文字が区別されないことを示しています。

FORTRANとSQL（およびCOBOL）が大文字と小文字を区別しない理由は、通常、通常の文字セットに大文字しか含まれていないマシンで使用するために設計されたためです。これらの言語の大文字小文字の区別は、（少なくとも）言語設計の選択というよりも歴史的な成果物です。

大文字と小文字を区別しないことを主張することもできますが、反対に、大文字と小文字を区別することでコードを読みやすくすることができます。

大文字と小文字の区別は有害と見なされます。

人生は大文字と小文字を区別せず、ユーザーもプログラマーでもありません。

大文字と小文字を区別する言語は、大文字と小文字を区別しない比較が困難である制約システムの歴史的な事故です。このハンディキャップはもはや存在しないため、大文字と小文字を区別するコンピューターシステムを再び作成する理由はありません。

コンピューターの利便性をユーザーの利便性よりも優先するため、大文字と小文字の区別は悪であると言えます。

（関連、私は数年前を思い出します、彼の名前がす​​べて大文字であるために、一部の天才は彼のクレジットカード請求書の支払いを拒否しましたが、彼はそれを大文字と小文字を混ぜて綴りました。有効な支払い要求。裁判官は議論を当然のように扱った。

私の個人的な経験から、大文字と小文字を区別する言語と区別しない言語の間に大きな違いはありません。

さらに重要なことは、プログラマーがコード内に保持する必要がある命名規則と構造規則であり、コンパイラーまたはパーサーはそれをチェックしません。ある種の規則に固執すれば、適切な名前を簡単に知ることができ（変数checkOutまたはCheckOutに名前を付けたとは思わないでしょう）、コードはおそらく大文字小文字を区別し、読みやすくなります。

同じ意味でCheckOutとcheckOutとcheckoutとcHeCkOuTとCHECKOUTを使用しないでください。それは可読性を損ない、その種のコードの理解をより苦痛に満ちたものにします（しかし、コードの可読性を破壊するためにできるもっと悪いことがあります）。

ある種のルールを使用すると、一目でわかるようになります。

CheckOut.getInstance（）-checkOut.calculate（）と呼ばれるクラスの静的メソッド-変数または_checkOut.calculate（）と呼ばれるパブリックフィールドに保持されるオブジェクトのメソッド-CHECKOUTと呼ばれるプライベートフィールドに保持されるオブジェクトのメソッド-それは最終的な静的または定数フィールド/変数です

他のファイルやファイルの一部をチェックアウトすることなく。コードの読み取りが速くなります。

Java、PHP、アクションスクリプト、JavaScript、C ++など、よく使用する言語で同様のルールを使用している開発者がかなりいます。

まれに、大文字と小文字を区別しないことに怒っている場合があります。たとえば、クラス名にCheckOutを使用し、変数にcheckOutを使用したい場合で、互いに衝突するため使用できない場合です。しかし、大文字と小文字を区別し、自分の命名規則でそれを使用することに慣れているのは、プログラマーの問題です。大文字と小文字を区別しない言語で、標準のプレフィックスまたはポストフィックスを使用したルールを作成できます（VBでプログラミングはしませんが、多くのVBプログラマーがこの種の命名規則を持っていることは知っています）。

ほとんどの開発者は大文字と小文字を区別する言語を使用し、ほとんどの開発者は大文字と小文字を区別する命名規則を使用しているため、大文字と小文字を区別するようにしたいので、大文字と小文字を区別する必要がありますなんらかの変更をせずにルールを守ることができます。しかし、それはむしろ宗教的な議論です-客観的なものではありません（本当の欠点や大文字と小文字の区別の良い側面に基づいていません）大文字と小文字が区別される場合でも、大きな違いはありません）。

プログラミング言語では大文字と小文字を区別しないでください。

最近の多くの言語で大文字と小文字が区別される主な理由は、単にカーゴカルト言語の設計です。そして、他の多くのものと同様に、Cはこれを明らかに間違っていました。

これは、実際にはCとUNIXの背後にある推進哲学の一部です。実装が簡単な悪いソリューションと実装が難しい良いソリューションのどちらかを選択できる場合は、悪いソリューションを選択し、混乱を回避する負担をかけますユーザー。 これはスナークのように聞こえるかもしれませんが、それは絶対に真実です。「最悪の方が良い原理」として知られ、過去数十年にわたってCおよびC ++が原因で数十億ドル相当の損害を直接引き起こし、グリッチで安全でないソフトウェアを書くのが非常に簡単になりました。

言語の大文字と小文字を区別しないようにするのは間違いなく簡単です。大文字と小文字を区別せずにすべてが一致することを確認するための特別な作業を行うために、レクサー、パーサー、およびシンボルテーブルは必要ありません。ただし、次の2つの理由から、これも悪い考えです。

• 最初に、特にスクリプト言語を作成する場合、ある場所では「myObject」、別の場所では「MyObject」と呼ぶ単純なタイプミスがあります。 、実行時エラーにはなりません。（これは、Pythonのように、これが間違っているスクリプト言語の主要な問題点として悪名高い。）
• 第二には、大文字と小文字の区別ができない場合の感度の手段を持っていない虐待され、同じ単語を持っているだけで総額を変更することにより、同じスコープ内の2つの異なるものを参照してください。C環境でWindowsコードを操作しなければならず、のようHWND hwnd;ない宣言に遭遇したことがあるなら、私が話していることを正確に知ることができます。そのように書く人は連れ出して撃たれるべきであり、言語の大文字と小文字を区別しないようにすることで、大文字と小文字の区別の乱用がコードに侵入するのを防ぎます。

それで、それを正しくするために余分な努力をしてください。結果として得られるコードは、よりクリーンで読みやすく、バグが少なくなり、ユーザーの生産性が向上します。それがプログラミング言語の究極の目標ではありませんか？

「大文字と小文字を区別してコードを読みやすくする」と誰かが言ったとは信じられません。

確かにそうではありません！Company and company（public variable Company、matched private variable company）と呼ばれる変数を同僚の肩越しに調べましたが、フォントと色の選択により、2つの違いを区別することは非常に困難です-隣り合っていても。

正しいステートメントは、「大文字と小文字を混在させるとコードが読みやすくなります」である必要があります。それははるかに明白な真実です。たとえば、companynameではなくCompanyNameおよびCompanyAddressという変数です。しかし、私が知っている言語では、小文字の変数名しか使用できません。

私が知っている最も狂った慣習は、「大文字のパブリック、小文字のプライベート」です。それは単にトラブルを求めているだけです！

私のエラーの受け止め方は、「静かに失敗したが成功したように見えるのではなく、何かがうるさく、できるだけ早く失敗する方が良い」です。そして、コンパイル時間よりも早くありません。

大文字を使用するつもりで誤って小文字の変数を使用した場合、同じクラス内でそれを参照していると、しばしばコンパイルされます。したがって、コンパイル時と実行時の両方で成功したように見えても、微妙に間違ったことをしている可能性があり、おそらくそれを長時間検出しない可能性があります。何か問題があることを検出したとき

プライベート変数に接尾辞が付いている規則を使用することをお勧めします-例：Company public variable、CompanyP private variable。誤って2つを混同する人はいません。それらはインテリセンスで一緒に表示されます。

これは、接頭辞付きのプライベート変数pCompanyがインテリセネの適切な場所に表示されないハンガリーの表記法に対する人々の反論とは対照的です。

この規則には、恐ろしい大文字/小文字の規則のすべての利点があり、欠点はありません。

私の意見では、人々が変数を区別するために大文字と小文字の区別に訴える必要性を感じているという事実は、想像力の欠如と常識の欠如の両方を示しています。または、悲しいことに、人間の羊は慣習に従う習慣が好きです。「それが常に行われている方法だから」

たとえ関連していても、作業するものを明確に、そして明らかに異なるものにします!!

非常に正当な理由がない限り、大文字と小文字を区別しないようにしてください。たとえば、Unicodeでの大文字と小文字の比較を処理するのは面倒です。古い言語の大文字と小文字の区別（またはその欠如）は、そのニーズが非常に異なっていたため、重要ではありません。

この時代のプログラマは、大文字と小文字を区別することを期待しています。

大文字と小文字の区別により、コードが読みやすくなり、プログラミングが簡単になります。

• 人々は大文字と小文字の適切な使用が読みやすいと感じます。

• 大文字と小文字が異なる同じ単語が関連するものを参照できるように、CamelCaseを許可/奨励Car car; します。したがって、指定carされた変数はtypeで作成されCarます。

• ALL_CAPS_WITH_UNDERSCORESは、多くの言語の規則により定数を示します

• all_lower_with_underscoresは、メンバー変数などに使用できます。

• 最新のプログラミングツール（ソース管理、エディター、diff、grepなど）はすべて、大文字と小文字を区別するように設計されています。大文字と小文字を区別しない言語を作成すると、プログラマーが当たり前のツールで問題を抱えることになります。

• 言語が解釈される場合、大文字と小文字を区別しないコードの解析によりパフォーマンスが低下する可能性があります。

• 英語以外の文字はどうですか？コプト語、中国語、ヒンディー語を決してサポートしないことに決めましたか？言語をすべてデフォルトのUTF-8にし、大文字または小文字が同等でない文字を持つ一部の言語をサポートすることを強くお勧めします。キーワードでこれらの文字を使用することはありませんが、さまざまなツールで大文字と小文字の区別をオフにし始めると（たとえば、ファイル内の物を見つけるために）、シュールで恐らく不快な体験に遭遇します。

利点は何ですか？あなたが言及する3つの言語は、1970年代以前のものです。これを行う現代言語はありません。

一方、エンドユーザーを実際に幸せにするものは、世界に少しの光をもたらします。それが本当にユーザーの幸福に影響するのであれば、あなたはそれをしなければなりません。

エンドユーザー向けに本当にシンプルにしたい場合は、大文字と小文字を区別/区別しないよりもうまくやることができます- スクラッチを見てください！数少ない漫画の猫とよりビジネスに優しい色で、私が今まで見た中で最も親しみやすい言語について知っています。あなたは何も書く必要はありません！ちょっとした考え。