どの命名規則を使用していますか?その理由は?
次の理由から、employeeNameTextBox を使用するのが好きです。
注: 省略形 (「tb」など) ではなくフル ネームを使用しています。これは、省略形の使用を避けるという MS の命名規則に沿っているためです。
最初にコントロール タイプ (textBoxEmployeeName) を名前に使用する唯一の理由は、Intellisense で簡単にグループ化できるようにするためです (すべてのテキスト ボックス コントロールが一緒に表示されます)。それを超えて、実際にその方法を使用するメリットはありません。私は 2 番目の方法 (employeeNameTextBox) の方が読みやすく、個人的にはその方法を好みますが、多くの人はまだ最初のコントロール タイプを使用します。
私は（ほぼ）常に [controltype][descriptive name] を使用しています。コードを見たときに、自分が扱っているコントロールの種類をすぐに知りたいのですが、名前を覚えていない場合は、Intellisense が助けてくれます。
わかりやすい名前 (EmplyeeName) を使用するだけではうまくいきません。コントロールの種類は？ラベル、テキスト ボックス、またはコンボ ボックスですか。それとも文字列？それともファイル？コントロールまたは変数のタイプが常にその一部であることは十分に重要です。
3 番目のオプションを提案します: uiEmployeName。理由:
私は通常、要素の種類を短くして、その後に識別ラベルを付けるようにしています。要素のタイプと目的をすばやく伝えることがわかりました。
txtEmployeeName;
lblEmployeeName;
WPF固有の回答：名前はまったくありません。
なんで？WPFを使用して開発している場合は、コントロールに名前を付けないでください。もしそうなら、あなたは何か間違ったことをしています。
WinFormsでは、データバインディングが非常に弱いため、コントロールに名前を付ける必要がありました。WPFは、次のすべてを解決します。コントロール自体がデータと動作を指定できるため、名前を付ける必要はありません。
Why not EmployeeName? Seriously how does the control type as part of the name when it is already provided by your IDE assist in delivering easy to maintain code? Consider Ottenger's Rules for Variable and class Naming
K
私が読んだように、質問で言及されている記事にリンクされている記事（つまり、Names of Resources）は、最後にコントロールタイプを使用していますFileMenu（ArgumentExceptionただし、コントロールではありません）。
私の個人的な意見では、これは従業員名のテキスト ボックスであるためemployeeNameTextBox、「ファイル メニュー」という単語がこの順序で読み取られるように、 という名前にする必要があるため、これも読みやすいと思います。(簡潔にするために「TextBox」の代わりに「Edit」を使用していますが、コントロール名を環境名と一貫して使用するという習慣をやめるべきでしょう。)
C# と Visual Basic の両方でコントロールに名前を付けるには、Microsoft のオブジェクト命名規則に従う方がよいと思います。
必読は、Jaime によってリリースされたXAML ガイドラインです。
こちらもご覧ください
I would go with [controlType][DomainTerm] which in this case is textBoxEmployeeName. The reason is that while coding for the C# code behind you are more care about the UI controls than the domain specific terms.UI(View) side coding we need to identify/recognize the control type faster, which is little more important than the domain specific name in the View side , and since we read from 'Left to right' this naming convention is relevant. I generally use txtEmployeeName or cmpEmployeeType , but textBox instead of txt is preferred as per MS guidelines
VB では、[ControlName]_[ControlType] を使用するのが好きです。どうやってそれを始めたのか覚えていませんが、論理的な順序のように感じたからだと思います. また、コードの提案がコントロールの種類ではなくコントロールの説明によってグループ化されるため、コーディングが少し簡素化されます。
C# でコントロールに同じ方法で名前を付けますが、キャメルケースに対する C# の設定に従っています: [controlName]_[controlType]。
また、あいまいではありませんが、コントロールの種類に独自の略語を使用する傾向があります。
例:
VB: Save_BtnとNewFile_MItem(メニュー項目)
C#: save_btnとnewFile_mItem
それは私にとってはうまくいきますが、もちろん、すべてのプログラマーには独自のスタイルがあります。
コードを読みやすく、自己文書化できるようにするためには、何でもする必要があります。厳格な規則に従うことは常に間違いです。なぜなら、それらの規則は、実行する必要があることのすべての側面をカバーすることはほとんどないからです。ガイドライン (ハンガリー語表記法を使用しないなど) を持つことは問題ありませんが、インターネットで見られるいくつかの規則に従うよりも、命名規則が何であれ、一貫性があり明確であることが重要です。
ハンガリー語表記は、いかなる形でもお勧めしません。textBoxEmployeeName は、ハンガリー表記の形式です。したがって、employeeNameTextBox の使用をサポートします。
個人的には、TextBox という言葉をわざわざ使用することさえありません。なぜなら、それは変数にとって重要なことではないからです。重要なのは「従業員」と「名前」です。TextBox という単語を追加すると、特定の型にロックインされるだけでなく、コードを正規化して正しくするために名前を変更する必要があるため、その型を変更することがはるかに難しくなります。何らかの理由でこれを TextBox として開始したが、後でこれを DropDownList またはその他のタイプに変更する必要があるとします。今度はすべてのコードと JavaScript を更新して、TextBox ではなく DropDownList と表示する必要があります。
変数名を入力しようとすることを忘れて、単純に名前を付ける方がはるかに簡単です。理由により、インテリセンスとコンパイル時のエラーチェックがありますが、それを使用しないでください。
アイデア:
エンコーディング/略語は避けてください。
この名前は、同じスコープ内の類似の名前よりも際立っている必要があります。最もユニークな部分を最も左の部分にします。複数のテキスト ボックスがあると思いますが、従業員名は 1 つだけです。
不必要な文脈を避ける。このページの名前はすべて従業員に関するものですか? 「従業員」ページですか？次に、EmployeeName は冗長です。NameBox または NameControl で十分です。
不必要なコンテキストを避ける: コントロールではない名前がありますか? もしそうなら、「ボックス」または「コントロール」は役に立ちますが、そうでなければあまり役に立ちません。
開示：私は「オッティンガー命名規則」の「オッティンガー」であり、「クリーンコード」の第2章にも発展しました。http://agileinaflash.blogspot.com/2009/02/meaningful-names.htmlで短い形式を参照してください。