ローカル変数（employeeCount、firstNameなど）の最初の単語に小文字を使用する理由は何ですか

すべての変数に適切な大文字小文字を使用しているため、他のプログラマーから多くの批判を受けています。たとえば、典型的なプログラマーはemployeeCount変数名に使用しEmployeeCountますが、私はを使用します。voidメソッド、returnメソッド、変数、プロパティ、定数など、すべてに適切な大文字小文字を使用します。Javascriptでもこの規則に従います。最後の1つは、人々のジミーを本当に擦ります。

この「非標準」の大文字と小文字の規則に従わない理由として挙げられる典型的な理由は、プロパティとvoidメソッドのために完全な適切なケースを予約する必要があるためです。値を返すローカル変数とメソッドには、のような小文字の最初の単語が必要int employeeCount = getEmployeeCount()です。

しかし、その理由はわかりません。

これに疑問を投げかけると、それが標準であるというarbitrary意的な答えを得るだけのようですです。答えが何であれ、それは通常、次のように常に要約されます。それに従うだけです。。任意の答えは決して私にとって十分ではありません。

Excel 97マクロをOffice IDEでプログラミングした初期の頃から、何かがローカル変数またはプロパティであるかどうかを判断するための大文字と小文字の規則は必要ありませんでした。これは、非常に直感的な命名規則を常に使用してきたためです。たとえば、GetNuggetCount()どこかに移動してすべてのナゲットのカウントを取得する方法を明確に提案しています。 SetNuggetCount(x)ナゲットのカウントに新しい値を割り当てることをお勧めします。 NuggetCountすべて単独で、単に値を保持しているプロパティまたはローカル変数を提案します。最後に、「ああ、それが問題だ。財産か変数か、それはどっち？」と言いたくなるかもしれません。それに対して、「本当に重要なのか？」と返信します。

tl; dr ;:変数または戻りメソッドの最初の単語に小文字を使用する客観的、論理的、非任意の理由は何ですか？

編集： MainMaの場合

このコードを回答の最初のコードサンプルに置き換えて、引数がどの程度維持されるかを確認します。

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

この命名規則は、変数にその型と同じ名前を付けたい場合によく使用されます。例えば：

Employee employee;

一部の言語では、大文字の使用も強制されます。以下のような迷惑な変数名を使用する必要がこれを防ぎMyEmployee、CurrentEmployee、EmployeeVar何かがちょうど総額から、型や変数の場合などは、いつでも伝えることができます。次のような状況で混乱を防ぎます。

employee.function(); // instance method
Employee.function(); // static method

また、英語では、名詞は一般的に大文字ではないため、大文字が「適切」であると主張することはできません。

それはあなたの状況と何の関係がありますか？明らかに、自分のコードを読むのに問題はありませんが、可能な限り一貫性を保つことにより、コードを読む必要がある他の人の精神的な作業負荷を軽減します。書面のようにコーディングする際には、読者に合わせてスタイルを調整します。

ありません。それはほとんどの人が行うことであり、それが標準となっています。多くの文献がこの慣習に従っているので、人々は習慣を取り戻しました。

規則は、コード全体の一貫性ほど重要ではありません。すべてのものが一貫した方法で命名されているので、それらを見ることで何かがわかるようになっていれば、最初の文字が大文字であるかどうかは問題ではありません。

あなたのやり方で書かれたコードに出くわすのは不快で、私はそれが好きではないと言うでしょう。しかし、それはスタイルの問題です。

職場でこれを行っている場合、コードがどこでも一貫性を保つように、チームのスタイルでコーディングする方が良いでしょう。コードを他の人とは異なるものにするのではなく。

http://thecodelesscode.com/case/9​​4

1.標準が存在する理由

結局のところ、個人の好みに応じて全員にコードを記述させ、どちらの標準が優れているかについて話すのをやめる方が良いと思いませんか？

実際、あるスタイルに慣れていると、別のスタイルを使用するコードを読むのが難しくなります。あなたの脳は、コードが何をするのかを理解するのではなく、（もしあれば）慣習を理解しようとしてより多くの時間を費やします。

これらの2つのコードの間で読みやすいものは何ですか？

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

または：

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

両方のコードは同様に実行されます。唯一の違いは、最初のケースでは、プロジェクトに取り組んだ各開発者が独自のスタイルを使用したことです。これにより、コードは一貫性がなくなり、判読できず、危険になりました。チームのメンバーがインデントのサイズについて同意できなかったという事実とif、コードのエラーが発生しやすくなった後、中の1人が中括弧の使用を拒否したという事実と相まって、それを見て、2つ目ifは最初の場合にのみ実行されifますが、そうではありません。

2番目のケースでは、すべての開発者が同じ標準に従いました。それらのいくつかは、2つのスペースのインデントを好むか、小さな文字で始まるメソッドに慣れているため、不幸かもしれません。実際のところ、コードはこの方法ではるかに読みやすく、異なる標準を使用している場合でもコードは読みやすくなります。

厳格で統一された標準を持つことにより、コードが読みやすくなります。

2.なぜ彼らの標準は私が今発明したものよりも優れているのですか？

世界中の何十万人もの開発者が標準を使用している場合は、そのままにしてください。自分で発明しないでください。たとえそれがより良いとしても、数十万人の開発者があなたのものを使い始めるよりも、グローバル標準に移行する方が簡単です。

例：私の会社では、データベースの主キーと外部キーおよびインデックスに名前を付けるための特定の規則があります。それらの名前は次のようになります。

• [FK for Application: CreatedByApplicationId]、
• [IX for SessionIPAddress: SessionId] または
• [PK for RoleOfPassword: RoleId, PasswordId]。

個人的には、この規則は非常に優れており、非常に明確だと思います。私のために。しかし、それは完全に最悪です。それは私のものだし、何千人ものデータベース管理者の誰もそれを使ったことがないからだ。この意味は：

• DBAを雇うと、彼はすぐに仕事を始めるのではなく、新しい慣習を学ぶことを余儀なくされます。

• インターネット上でコードの一部をそのまま共有することはできません。これらの奇妙に見える名前は、私のコードを読む人を混乱させ、

• 自分で使用するために外部からコードを取得した場合、統一するために名前を変更する必要があり、

• ある日、よく知られた標準を使用することに決めた場合、数百の名前すべてを変更する必要があります。

3.では、大文字化はどうですか？

プロパティは、フィールドまたはローカル変数よりも大きなスコープまたは可視性を持ちます。プロパティの作成は大文字で始まり、フィールドと変数-小さなものはこの方向に進みます。

C＃を検討する場合、このロジックは十分に一貫しています。

Javaを検討する場合、メソッドは小さな文字で始まりますが、これはロジックに従っていません。

だから、この規則があなたのものより良いという決定的な証拠はありません。それはグローバルに使用されるものであり、あなたのものではありません。どれも優れていません。

JavaScriptでは、new前に必要な場合を除き、関数は小文字で始まります。他の方が良いと思いませんか？多分。実際、JavaScript開発者は長年にわたってこの標準を使用しており、その反対ではありませんでした。すべての本を書き直し、すべての開発者にスタイルの変更を強制することは、少し複雑になります。

技術的には、問題ではありません（少なくとも、ほとんどの言語では問題ありません）。

ただし、ほとんどのプログラミングコミュニティ（特定の言語を中心に形成された世界規模のコミュニティ、そのようなコミュニティのサブグループ、人気のあるライブラリやツールキットを中心に形成されたグループ、または個々のチーム）は、確立されたコーディング標準を開発しています。正確な詳細は、（多くの場合、良い引数は彼らのために行うことができるが）比較的重要でない、何で重要なことは、あなたがそれらに固執するということです。

彼らが最高だからではなく、彼らが誰もが使用しているからです。標準に固執する場合、最終的に使用する他のほとんどのコード（ライブラリ、チームメイトのコード、組み込み言語）とコードの一貫性が保たれます。一貫性のある命名は、生産性の強力な武器の1つです。これは、何かの名前を推測すると、通常は正しく推測できることを意味するためです。それはfile.SaveTo()、File.saveTo()、file.save_to()、FILE.save_to()？命名規則からわかります。

第一に、すべての言語には独自の文化があり、命名規則はしばしば互換性がないため、遭遇するすべての言語に個人的な好みを持ち込むことは特に危険です。第二に、命名に関する限り、言語間に多くの微妙な違いがあります。

ほんの一例です。C＃では、型と変数は別々の名前空間に存在します。コンパイラーは、違いを知るのに十分なほど賢いです。ただし、Cでは、両方の種類の名前が名前空間を共有するため、同じスコープ内に同じ名前の型と変数を含めることはできません。このため、Cでは型と変数を区別する命名規則が必要ですが、C＃では必要ありません。

私は誰もこれを言っていないことに驚いていますが、大文字の違いは1つの理由で驚くほど役立つと思います：変数がローカルスコープのみであるかどうかを知ることができて便利です。変数がローカルである場合、名前のリファクタリングなど、変数を変更する副作用についてはあまり心配しません。したがって、クラスメンバーとプライベートクラス変数とローカル変数を区別する規則が好きです。

最新のIntelliSenseでは、これは重要性を失いますが、コードを読んで定義を見つけるためにどこを探すべきかを知る際のランドマークを与えてくれます。

そして、メソッドが1つの画面に収まらない可能性があった数年前の私の悪いスタイルから、これのかなりの部分が残っているかもしれません。

これは、特定の規約というよりも規約の問題のようです。

あなたが破るすべての慣習に対して、あなたは他の皆のためにより多くの仕事を追加しているだけです。おそらく完璧な世界では、会社全体が生涯にわたって単一の製品で作業していますが、実際には、これは真実ではありません。人々はプロジェクト間をジャンプし、時には企業間で、あるいは楽しみのためにジャンプします。コードがランダムであるほど、作業が難しくなり、費用がかかります。事業主または利害関係者として、プロジェクトの利益のためではなく、利己的に考える開発者を雇いたくありません。

これはプロフェッショナリズムに帰着します。時々、私たちの個人的なスタイルを脇に置いて、大量採用のためにより効率的なものを選ぶ必要があります。これにより、コラボレーションが促進され、そもそも存在しないはずの無関係な障壁が取り除かれます。

実際の慣習として、CapitalCamelCaseは通常クラス名（またはJavascriptではコンストラクター）のために予約されています。大文字の変数が表示された場合、経験に基づいた推測により、使用するためにインスタンス化する必要があります。それが間違っている場合、コードがコミュニティの標準に従っていないことに腹を立てます。他のほとんどの言語でさえ、初めてそれを見る他の誰もが即座に誤解されています。コードは誤解を招くものではなく、明らかにする必要があります。

「プロパティとvoidメソッドには完全な大文字と小文字を予約する必要があります。ローカル変数と値を返すメソッドには、最初の単語を小文字にする必要があります」と標準の規則です。

他のプログラマーはあなたのコードを今すぐ引き出しており、これはプロパティであり、実際にはローカル変数であると考えており、仕事を難しくしています。

他の人が本当の理由を言っていないように、名前付け規則を軽くすることを除いて。チーム全体を同じページにまとめることができれば、おそらく時間を節約できます。例えば、個人的にはコーディング標準を始めました。これはすべてのプライベート変数とValで渡されたものにcamelCaseを使用しましたが、公開されたものとRefで渡されたものにはPascalCaseを使用しました。

保護されている、Out、または何かのようなものを扱うとき、線は少しぼやけます。

言語（その正式な側面と従来の）は、あなたの思考を整理するために重要であり、あなたの考え方を支配する力を持っています。そのため、あるスタイルから別のスタイルに移行するのは苦痛です。

小文字のシンボルと大文字のシンボルは、Haskellで大きな意味の違いがあり、Scalaでもわずかに異なります。私は両方とも使用しました。私が使用する他の言語では、この2種類の識別子に違いはありませんが、Haskellが識別子を認識する方法を考えておくと、異なる言語で頭を断片化するよりもはるかに簡単になります。

私にとっては期待にかかっています。

ほとんどのコードを読むと、 lowerCaseローカル変数または関数（C＃では変数になります）になることを期待しています。にローカル変数ProperCaseが表示された場合、クラス名またはプロパティまたは他の何かであると考えて、つまずき、しばらく混乱する可能性があります。それは私にコードを再読させ、私を悩ますでしょう。

それはおそらくあなたのケースで起こっていることです。

さらに、最初の文字を見るだけで変数がどのような役割を果たしているかを知ることができ、インスタンス名とクラス名の衝突を回避できます。

入力しやすいように、ローカル変数には小文字を使用する必要があります（速度/シフトキーなし）。大文字は、名前内の単語を区切って読みやすくするために使用されます。シングルワードのローカル変数名（これは一般的であるはずです）を含むコードは、高速で簡単に入力できます。名前の新しい単語ごとに大文字を使用することは、別の文字を追加するアンダースコアを使用するよりも高速です（スペースが少なくなります）。これはキャメルケースとも呼ばれます。

ここのOPに同意します。camelCaseは間違っているように見えます。また、それが標準であり、同じ標準に固執しなければならないという事実、または標準を持つことのポイントに同意します。また、PascalCapsをメソッドなどに使用し、キャメルケースを独自の変数などに使用して、メソッドを色付けするIDEを使用しない場合に差別化することもできます。

それを回避するために、私は常にオブジェクトの名前の前にオブジェクトのタイプを付けます。したがって、文字列変数の場合、strMyVariableを呼び出します。何らかのオブジェクトである場合、objMyObjectなどと呼びます。そのように、標準に従って小さな大文字で始まり、正しく見えます。