ここでゆっくりと言語を開発しています。 そして、膨大な数の構文的およびセマンティックな質問に加えて、インターフェイスの質問を解決する必要があります（それを呼び出すことができます）。 したがって、これらの質問の1つは、プログラマが識別子を構成できる文字と、大文字と小文字を区別するかどうかという質問です。 質問は簡単ではありません。その理由は次のとおりです。
短い間書:)。 実際、私はほとんど常に
this_is_the_variableのスタイルで書きました。もしPlan9コードを見ていなければ、質問はありません。「Cのような」言語で識別子を作成していましたが、Plan9を読んだことがあります。 LinuxのソースよりもPlan9のソースを理解する方がはるかに簡単だったという事実は、私に鋭い誤解を引き起こしました。 そして、これはPlan9変数では通常
wrblock 、
lzput 、
hufftabinit 、
quotefmtinstallように、Linuxでは
wrblock 、
lzput 、
hufftabinit 、
quotefmtinstallように名前が付けられているという事実にもかかわらず
seq_puts 。 なぜそう 自分自身に説明をしようとすると、誰かに役立つと思います。
ご存じのように、いくつかの一般的な語彙変数の命名スキームがあります。
this_is_the_var
thisIsTheVar
thisisthevar
したがって、コードを理解するのにどちらが良いかは、未解決の問題です。 標準的な観点があります：
this_is_the_varは最適なオプションです。識別子を構成する単語をすぐに解析できるためです。 しかし、それが良いか悪いかは論点です。 なぜなら…
まず、識別子によって抽象化されたプロセスの説明を通じて識別子の意味を表現するよう努力する必要がありますか？ たとえば、
printfが
printfであることは誰もが知っているので、それが実際に何であるかについて誰も本当に考えていません：
print_values_with_formatting_on_standart_output または、誰もが
stdoutが
stdoutことを知っています。 識別子の名前に識別子を入れるのは理にかなっていますか、それとも識別子の意味がプログラムのテキストから派生しているときに、プログラムのテキストを知覚して書く方が良いでしょうか？ そして、2番目が真である場合、そしてその逆の場合、長い名前はテキストの認識を妨げますか？ さらに、長い名前はテキストの理解を妨げますか？ 実際、
this_is_the_variableの場合
this_is_the_variableプログラマーは2つのレベルで作業する必要があります。識別子を識別するフレーズの意味を評価することと、プログラム全体と識別子の関係を評価することです。 例として：
while（（current_character = getc（stdin））！= EOF）
{
do_something（）;
}
そして
while（（c = getc（stdin））！= EOF）
{
do_something（）;
}
例は単純ですが、最初のケースでは、まず
current_character読んで、これが現在の文字であることを理解してから、この理解を
getc動作方法に
getcください。この精神構造（これは科学的な事実ではありませんが、私の仮説は素人です）。 2番目の例では、これは発生しません
cの意味
c 「象形文字」です。つまり、外部言語へのアピールによって識別子に埋め込まれませんが、ここではプログラムのテキスト（画像、つまり象形文字と言うことができます）にあります。 これは便利ですか？ 私は個人的に知りませんが、それについて考える可能性があります（？）。
第二に、これは前のものを補完するもので、
this_is_the_variableのスタイルの識別子は、脳が全体として識別子を知覚することを単に混乱させます。 たとえば、GitHubを検討すると、変数宣言がどこから始まるのかを理解しようとして、比較的長い時間、音節ごとに1行だけを読むことがあります。 または、
lpfnWndProcと
window_event_handling_procedure_ptr比較できます。これは全体として認識されますか？
第三に、何かを詳細に記述する長い識別子は、書かれていることの意味を理解するために分析する必要があるフィールドを物理的に拡張します。
これはすべて疑問につながります：識別子にアンダースコアを使用できるようにする必要があり、それによってプログラマに冗長性とマルチビットを刺激しますか？
別の質問：識別子は大文字と小文字を区別する必要がありますか？ この質問に対する一般に受け入れられている答えは、そうです。 しかし、ここでも、あなたは疑問を表現することができます：例えば、そのような。 大文字と小文字を区別しないため、プログラマーはより自由にやり取りできます：1つは
lpfnWndProcを記述し、もう1つは
lpfnWndProcを記述する方が便利です。3つ目は、さまざまな種類のループに異なるマークを付けます。たとえば、
foRはリスト
foRを実行し、
FORは数値解の反復検索です。
小さな余談：それにもかかわらず、数値はアルゴリズムであり、数値-座標、または数値-値よりもはるかに自然です。このトピックに関するさまざまな論争と議論に対処し、大文字と小文字を区別しないアンダースコアなしの識別子を作成するのは悪いことだという発言に出くわしました。重要です。 しかし、私たちの言語では、このような識別子を作成することができます：ID。そのような識別子
ID.' ? !' ID.' ? !' 、Cおよびその他の大文字と小文字を区別する言語のライブラリと通信するために使用できます。 下線と大文字と小文字を区別して変数を実行する価値はありますか？ そして、これらの機能の欠如は、より良いコードの記述に貢献し、それからそれをより良く理解するでしょうか？
そのようなテキストは判明しました。 ご清聴ありがとうございました。
PS Plan9の開発者であるRob PikeがCプログラミングルールについて書いたものは次の
とおりです
。www.lysator.liu.se /
c /
pikestyle.html