言語の大文字と小文字を区別しないキーワード
カスタムスクリプト言語を作成しようとしています。 大文字と小文字を区別しないキーワードを提供して、言語を寛容にする提案がありました。
私は個人的にはこのアイデアが好きではありませんが、エンドユーザーを幸せにするだろうと言って、チームにそれを傾けている人はほとんどいません。 FORTRAN、BASIC、SQLなどの言語の例では、これらは大文字と小文字を区別しないとされています。
これは良い考えですか？
エンドユーザーが誰であるかを自問してください。 CやJavscriptでのプログラミング経験、またはUnixでのIT経験を持っている人が書くことを意図している場合、ユーザーが期待するとおり、大文字と小文字を区別することはおそらく正しいことです。しかし、ほとんどのエンドユーザー、さらにはパワーユーザーにとって、これは混乱を招きます。
VB/VBA/VBScriptは大文字と小文字を区別しません。これは、プログラマーでない人が簡単に言語のこつを得られるようにするための決定です。正確なスクリプトではなく、多くのユーザーが取得するExcelの数式では、大文字と小文字は区別されません。ほとんどの執筆では、大文字と小文字を選択することで、テキストを多かれ少なかれ専門的で洗練された見た目にすることができますが、大文字と小文字を区別しても、単語のsemanticの意味は変わりません。そのため、開発者以外のユーザーは、大文字と小文字を区別するスクリプト言語に混乱することになると思います。
繰り返しますが、これは技術的な選択ではありません。これは、対象となるオーディエンスをよく知っている人々が行う必要がある製品管理の選択です。
実装の容易さや難しさではなく、提示したいユーザーエクスペリエンスに基づいて決定する必要があります。
ユーザーが大文字と小文字を区別しないようにすることが容易になる場合は、それを実装する必要があります。
例として、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でのケース処理によって引き起こされる厄介な問題を見てください。それは技術的な問題です。大文字と小文字を区別するファイルシステムは、大文字と小文字を区別しないファイルシステムでは問題にならない外部データに問題があります。
一般的なLISPは理想的なアプローチを採用しています。シンボル名では大文字と小文字が区別されますが、トークンが読み取られると、大文字に変換されます。これは、トークンfoo、fOO、FOOおよびFooがすべて同じシンボルを表すことを意味します。名前が文字列"FOO"として保存されているシンボルです。さらに、この動作はデフォルトの読み取りテーブル構成にすぎません。リーダーは、文字を大文字、小文字に変換したり、大文字を反転したり、保持したりできます。最後の2つの選択肢は、大文字と小文字を区別する方言を生じさせます。これにより、ユーザーは最大限の柔軟性を得ることができます。
本当の決定要因は、同じ名前のものが複数あることを望む頻度です。 SELECTという名前の列が必要になることはあまりないため、SQLでは大文字と小文字を区別しません。他のすべての行がObject object = new Object()のように見えるため、Javaの場合、クラス、インスタンス、およびコンストラクタを同じ名前で参照する必要があるため、煩わしいでしょう。
つまり、大文字と小文字の区別は名前のオーバーロードに最も役立ち、オーバーロードは大規模で複雑なプロジェクトでほとんどの場合役立ちます。スクリプト言語などの使用頻度が低い場合は、大文字と小文字を区別しないため、プログラミングがはるかに簡単になります。
識別子が大文字と小文字を区別するだけでなく、空白を区別しない場所でルール言語を作成しました。同じ識別子を参照するエイリアスの作成も許可しました。たとえば、ProgrammersStackExchange、プログラマスタック交換、およびPSEはすべてまったく同じシンボルに解決され、互換的に使用できます。
私のドメインが非常にうまく機能したのは、そのドメインが同じものを参照するための非常によく知られた多くの方法を持っていて、名前の競合がまれだったからです。ある名前を使用してクエリを入力し、その結果に別の名前を使用しても、誰も驚かないでしょう。言語サポートがあると、ドメインとプログラミング言語の間の変換が非常に簡単になります。ただし、変数へのすべての参照を見つけるなど、特定のタスクが困難になりました。ありがたいことに、私の場合、このような状況はめったに発生しなかったか、支援するためのツールサポートを構築するのがかなり簡単でしたが、自分の状況を考慮する必要があります。
スクリプト言語で大文字と小文字が区別されると仮定します。ユーザーが変数名またはキーワードで間違った大文字と小文字を使用してタイプミスをしたかどうかをユーザーに知らせるコンパイラまたは構文チェッカーを作成しますか？そうでなければ、それは言語の大文字と小文字を区別しないようにするための非常に強力な議論になります。
オンザフライで変数を宣言できますか？もしそうなら、私は大文字と小文字を区別しないと主張します。
ATypo = 42;
とは対照的に
Atypo = 42;
2つのステートメントを同等にすると、作業が楽になるだけで、デバッグ時間を不必要に要求します。
FORTRAN、BASIC、SQLなどの言語の例では、これらは大文字と小文字を区別しないとされています。
FORTRANとSQL（およびCOBOL）が大文字と小文字を区別しない理由は、それらが元々、通常の文字セットに大文字しかなかったマシンで使用するように設計されていたためです。それらの言語での大文字と小文字の区別は（少なくとも）言語の設計の選択よりも歴史的なアーチファクトです。
ここで、大文字と小文字を区別しない方が寛容であると主張できますが、裏側は、大文字と小文字が区別されるため、コードが読みやすくなるためです。
「大文字と小文字を区別することでコードが読みやすくなる」と誰かが言ったことは信じられません。
それは間違いなくありません！私は、会社と会社（パブリック変数会社、マッチしたプライベート変数会社）と呼ばれる変数を同僚の肩越しに調べました。彼のフォントと色の選択により、2つの変数の違いを見分けるのが非常に難しくなっています。
正しいステートメントは、「大文字と小文字を混在させるとコードが読みやすくなる」ということです。それははるかに明白な真実です-例えばcompanynameではなくCompanyNameおよびCompanyAddressと呼ばれる変数。しかし、私が知っている言語では、小文字の変数名しか使用できません。
私が知っている最も狂った慣例は、「大文字のパブリック、小文字のプライベート」の慣例です。お手数ですがよろしくお願いします！
私のエラーについては、「静かに失敗して成功したように見えるよりも、何かが騒々しく、できるだけ早く失敗するほうがいい」としています。そして、コンパイル時間よりも早くはありません。
大文字を使用するつもりで誤って小文字の変数を使用すると、コンパイルされます同じクラス内でそれを参照している場合。したがって、コンパイル時と実行時の両方で成功したように見えても、微妙に間違った処理を行っている可能性があり、おそらくそれを長時間検出しない可能性があります。何か問題があることを検出した場合
プライベート変数にサフィックスがある規約を使用する方がはるかに優れています-たとえばCompanyパブリック変数、CompanyPプライベート変数。 Nobodyが誤って2つを混同し、それらがインテリセンスに一緒に表示されます。
これは、ハンガリー語の表記法に対する異論とは対照的です。ハンガリー語の表記では、プレフィックス付きのプライベート変数pCompanyがインテリセネの適切な場所に表示されません。
この規則には、恐ろしい大文字/小文字の規則のすべての利点があり、欠点はありません。
変数を区別するために大文字と小文字を区別する必要があると人々が感じているという事実は、想像力の欠如と常識の欠如の両方を示していると私は考えています。または、悲しいことに、人間の羊は慣例に従う習慣のようです。なぜなら、「それが常に行われている方法だからです」
関係のあるものも含めて、作業内容を明確かつ明確に異なるものにしてください。
プログラミング言語では大文字と小文字が区別されません。
最近の多くの言語で大文字と小文字が区別される主な理由は、単にカーゴカルト言語の設計にあります。そして、他の多くのことと同様に、Cはこれを明らかに間違っています。
これは実際にはCとUNIXの背後にある推進哲学の一部です：実装が簡単な悪いソリューションと実装が難しい良いソリューションのどちらかを選択できる場合は、悪いソリューションを選択してプッシュしますユーザーへの混乱を回避する作業の負担。これはひどく聞こえるかもしれませんが、それは完全に本当です。これは「悪い方が良い原則」として知られており、過去数十年にわたってCおよびC++による数十億ドル相当の損害の直接の原因となっており、グリッチで安全でないソフトウェアの作成が非常に簡単になっています。
言語の大文字と小文字を区別しない方が間違いなく簡単です。大文字と小文字を区別しない方法ですべてが一致することを確認する追加の作業を行うために、レクサー、パーサー、およびシンボルテーブルは必要ありません。しかし、次の2つの理由から、これも悪い考えです。
- まず、特にスクリプト言語を作成している場合、ある場所で「myObject」を呼び出し、別の場所で「MyObject」を呼び出す単純なタイプミスです。明らかに同じオブジェクトを参照していますが、大文字と少し矛盾しています、実行時エラーにはなりません。 （これは、Pythonなど、これを誤るスクリプト言語の大きな問題点として悪名高いです。）
- 第二に、大文字小文字の区別がないことは、大文字と小文字の区別をabuseして、同じWordを変更するだけで同じスコープ内の2つの異なるものを参照することができないことを意味します大文字。 C環境でWindowsコードを操作し、
HWND hwnd;のような醜い宣言に遭遇したことがあるなら、私が何を話しているのか正確にわかるでしょう。そのように書く人は連れ出されて撃たれるべきであり、言語の大文字と小文字を区別しないようにすることで、大文字と小文字の区別の悪用があなたのコードに侵入するのを防ぎます。
だからそれを正しくするために余分な努力をしてください。結果のコードは、よりクリーンで読みやすく、バグが少なく、ユーザーの生産性が向上します。これは、プログラミング言語の最終的な目標ではありませんか？
大文字と小文字の区別は有害と見なされます。
人生は大文字と小文字を区別しませんし、ユーザーやプログラマーも同様です。
大文字と小文字を区別する言語は、大文字と小文字を区別しない比較が困難である制約されたシステムの歴史的な事故です。このハンディキャップはもはや存在しないため、大文字と小文字を区別するコンピューターシステムを再び作成する理由はありません。
大文字と小文字の区別は悪ですと言って、コンピュータの利便性を優先しています。ユーザー。
（関連して、私は数年前に思い出しました、彼の名前がすべて大文字だったので、何人かの天才は彼のクレジットカードの請求書を支払うことを拒否しました、しかし彼はそれを混合大文字で綴りました。正当な支払い要求。裁判官はその主張を当然のように扱った。
私の個人的な経験から、大文字と小文字を区別する言語と区別しない言語の間に大きな違いはありません。
より重要なことは、プログラマーがコード内に保持する必要がある命名規則と構造規則であり、コンパイラーやパーサーはそれをチェックしません。ある種のルールを守ると、適切な名前を簡単に知ることができ（変数にcheckOutまたはCheckOutという名前を付けたとは思わないでしょう）、コードでは大文字と小文字が区別され、読みやすくなります。
CheckOutとcheckOutとcheckoutとcHeCkOuTとCHECKOUTを同じ意味で使用しないでください。それは読みやすさを損ない、その種のコードの理解をより困難なものにします（しかし、コードの読みやすさを破壊するためにできることがもっと悪いこともあります）。
たとえば、ある種のルールを使用すると、一目でわかるようになります。
CheckOut.getInstance（）-これは、checkOut.calculate（）と呼ばれるクラスの静的メソッドです。これは、_checkOut.calculate（）と呼ばれる変数またはパブリックフィールドに保持されるオブジェクトのメソッドです-CHECKOUTと呼ばれるプライベートフィールドに保持されるオブジェクトのメソッドです-最終的な静的または定数フィールド/変数です
他のいくつかのファイルまたはファイルの一部をチェックアウトせずに。コードの読み取りが速くなります。
かなり多くの開発者が、Java、PHP、アクションスクリプト、JavaScript、C++など、よく使用する言語で同様のルールを使用しています。
まれなケースでは、大文字と小文字を区別しないことに腹を立てる可能性があります。たとえば、クラス名にCheckOutを使用し、変数にcheckOutを使用したいが、衝突するため使用できない場合などです。しかし、大文字と小文字を区別し、彼の命名規則で使用するのは、プログラマーの問題です。大文字と小文字を区別しない言語で標準のプレフィックスまたはポストフィックスを含むルールを設定できます（VBでプログラムしていませんが、多くのVBプログラマーがこの種の命名規則の）。
つまり、ほとんどの開発者は大文字と小文字を区別する言語を使用しており、ほとんどの開発者は大文字と小文字の区別に基づいた命名規則を使用しているため、言語の大文字と小文字を区別する方が良いので、大文字と小文字が区別されます。なんらかの変更を加えることなく、ルールを守ることができます。しかし、それはむしろ宗教的な議論です-客観的なものではありません（実際の欠点や大文字と小文字の区別の良い面に基づくものではありません）。bAdDeVeLoPeRに関して言えば、悪夢のようなコードを生成する可能性があるためです。大文字と小文字が区別される場合でも、大きな違いはありません）。
大文字と小文字を区別しない理由は、十分な理由がない限り導入しないでください。たとえば、Unicodeでの大文字と小文字の比較を処理するのは難しい場合があります。古い言語の大文字と小文字の区別（またはその欠如）は重要ではありません。なぜなら、それらのニーズは非常に異なっていたからです。
この時代のプログラマーは大文字小文字の区別を期待しています。
大文字と小文字を区別することで、コードが読みやすくなり、プログラミングが容易になります。
人々は 大文字と小文字の混合を適切に使用すると読みやすくなります を見つけます。
CamelCaseを許可/奨励し、大文字と小文字が異なる同じWordが関連するものを参照できるようにします：
Car car;したがって、carという名前の変数はCar型で作成されます。ALL_CAPS_WITH_UNDERSCORESは、多くの言語の規約により定数を示します
all_lower_with_underscoresは、メンバー変数などに使用できます。
すべての最新のプログラミングツール（ソース管理、エディター、diff、grepなど）は、大文字と小文字を区別するように設計されています。大文字と小文字を区別しない言語を作成すると、プログラマーが当たり前と思うツールで問題が永遠に続くことになります。
言語が解釈される場合、大文字と小文字を区別しないコードの解析により、パフォーマンスが低下する可能性があります。
英語以外の文字はどうですか？コプト語、中国語、ヒンディー語をサポートしないことにしましたか？言語をすべてデフォルトでUTF-8にし、対応する大文字または小文字のない文字を含む一部の言語をサポートすることを強くお勧めします。キーワードでこれらの文字を使用することはありませんが、さまざまなツールで大文字と小文字の区別をオフにし始めると（たとえば、ファイル内のものを検索するため）、シュールで恐らく不愉快な経験に遭遇します。
メリットは何ですか？あなたが言及する3つの言語は1970年代以前のものです。これを行う現代の言語はありません。
一方、実際にエンドユーザーを幸せにするものは、世界に少し光をもたらします。それが本当にユーザーの幸せに影響を与えるなら、あなたはそれをしなければなりません。
エンドユーザーにとって本当に簡単にしたい場合は、大文字と小文字を区別する/区別しないよりも上手くできます Scratch を見てください！数匹の漫画の猫が少なく、ビジネスにやさしい色で、私が今まで見た中で最も親しみやすい言葉を持っています-何も書く必要はありません！ちょっとした考え。