C # GUI 명명 규칙에 대한 모범 사례?

C # GUI 명명 규칙에 대한 모범 사례?

---

WinForms 또는 XAML로 작성된 GUI는 내가 본 프로젝트간에 가장 널리 다른 명명 규칙을 가지고있는 것 같습니다. TextBox사람의 이름을 간단하게 하기 위해 다양한 명명 규칙을 보았습니다.

TextBox tbName      // Hungarian notation
TextBox txtName     // Alternative Hungarian
TextBox NameTextBox // Not even camelCase
TextBox nameTextBox // Field after field with TextBox on the end
TextBox TextBoxName // Suggested in an answer...
TextBox textBoxName // Suggested in an answer...
TextBox uxName      // Suggested in an answer...
TextBox name        // Deceptive since you need name.Text to get the real value
TextBox textBox1    // Default name, as bad as you can get

나는 모든 .cs 파일에 대한 StyleCop 규칙을 일반적으로 준수하고 다른 사람들도 그렇게하는 것을 보지만 GUI는 이러한 규칙을 위반하거나 크게 달라지는 경향이 있습니다. 일반 변수 대신 GUI 요소를 구체적으로 언급하는 Microsoft 지침이나 콘솔 응용 프로그램 외부에 적용되는 예제를 본 적이 없습니다.

GUI에서 요소 이름 지정에 대한 모범 사례는 무엇입니까?

---

나는 구식 헝가리어 ... txt를 TextBox, btn을 Button, 일반화 된 단어, 더 구체적인 단어를 차례로 사용합니다. 즉 :

btnUserEmail

많은 사람들이 "너무 늙었 어, VB6 전화!" 그러나 UI Rich winforms 앱에서는 일반적으로 컨트롤에 대해 가장 먼저 아는 것이 유형, 범주, 구체적으로 파악하기 때문에 항목을 더 빨리 찾고 수정할 수 있습니다. 새로운 스타일의 명명 규칙은 텍스트 상자의 이름을 기억하려고 애 쓰고 있습니다.

컨트롤의 원래 사양은 여기에 있습니다 (보관 됨).

---

나는 사용한다:

TextBox nameTextBox;

내가 사용하는 것처럼 :

MailAddress homeAddress;

그 이유는 이러한 경우 "TextBox"및 "Address"가 개체가 나타내는 내용을 설명하는 것이지 저장 또는 사용 방법이 아니기 때문입니다. 그러나 사람의 이름을 저장하는 것과 같은 다른 경우에는 다음을 사용합니다.

string fullName;

아니:

string fullNameString;

"String"은 객체가 나타내는 내용을 설명하는 것이 아니라 저장 방법 만 설명하기 때문입니다.

---

.NET의 다른 모든 것과 동일한 규칙 : 낙타 대소 문자를 설명하는 이름 만, 동일한 논리적 "사물"에 대해 서로 다른 클래스를 구별해야하는 경우 선택적으로 접미사가 붙습니다. 예를 들면 :

string name; // a name
TextBox nameText; // the control used to edit the name
Label nameLabel; // the control used to label the edit control
List<string> nameList; // a list of names

등등 광고 무한. 일관되고 설명적인 접미사가 무엇인지는 정말 중요하지 않습니다.

---

이것은 내 발명품은 아니지만 좋아합니다.

TextBox uxName = new TextBox();
Label uxNameLabel = new Label();
Button uxAccept = new Button();

모든 UI 컨트롤이 인텔리 센스의 한 블록에 표시되기 때문에 헝가리 표기법보다 이것을 선호합니다. "사용자 경험"을위한 UX. 컨트롤을 텍스트 상자에서 콤보 상자 등으로 변경하면 이름이 변경되지 않기 때문에 좋습니다.

---

나는 누군가가이 주제에 대한 권위자가되고 그것을 그대로 말하고 시행하기를 바란다. 나에게 가장 나쁜 것은 사람들이 같은 응용 프로그램이나 더 나쁘지만 같은 클래스에서 그것을 섞을 때이다.

txtName, NameTextBox, name 및 textBox1이 모두 같은 형태로 사용되는 꽤 끔찍한 것들을 보았습니다.

내가 일하는 곳에서는 어떻게해야하는지, 어디서해야하는지 알려주는 표준 문서가 있으며, 20 %의 사람들 만이 노력하고 준수하는 데 관심이 있다고 생각합니다.

Fxcop이 나에게 소리를 지르면 나는 보통 무언가를 바꿀 것입니다.

http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29

대문자 스타일

참고 : Microsoft .NET은 대부분의 식별자에 대해 UpperCamelCase (일명 "Pascal Style")를 권장합니다. (매개 변수에 대해 lowerCamelCase가 권장 됨).

---

명명 규칙에서 가장 중요한 것은 의미있는 것을 선택하고, 모든 당사자의 합의를 얻고, 삶이 그것에 의존하는 것처럼 그것을 고수하는 것입니다.

어떤 규칙을 사용할 지에 대해 나는이 규칙에 투표 할 것입니다.

TextBox name

짧고 의미 론적 값을 식별자로 가지고 있습니다. 식별자 유형 에 관해서는 Visual Studio에 의존하여 그런 종류의 일에 능숙한 경향이 있음을 알려줍니다.

---

나는 약간의 차이가있는 Hungation 표기법을 사용합니다.

저는 현재 상당히 풍부한 UI를 가진 프로젝트를 진행하고 있습니다. 따라서 Intellisense를 사용하면 btnGetUsers라는 버튼을 매우 쉽게 찾을 수 있습니다.

애플리케이션이 다른 위치에서 사용자를 가져올 수 있으면 상황이 복잡해집니다. 그것은 다른 컨트롤입니다. 그래서 컨트롤의 위치를 ​​따서 이름을 짓고 헝가리 표기법을 사용했습니다.

As an example: tabSchedAddSchedTxbAdress means that txbAddress is a text box where an address can be inserted and is located on the Add Scheduling tab from the Scheduling Tab Control. This way I can find controls very easy and, when I type simply "btn" I don't get, at once, a lot of buttons from all over the user interface.

Of course this is just to help myself. I'm not aware of such a best practice. However it helps a lot.

Mosu'

---

I name all my UI elements TypeDescriptor. Following your example, TextBoxName.

---

I've been working with a team lately that is moving from MFC (6.0 ...). There they would have something like

CString Name;
CEdit ctlName;

The easiest way to migrate has been to use something like

TextBox ctlName

It's just enough of a reminder that the variable is the control and not the value of the control.

I think including the type as a part of the name is just OLD.

-- edit -- Another benefit is that all of the controls are grouped together when navigating. If the actual type were used, the ComboBox controls would be quite far from the TextBox controls.

---

I tend to use c_typeName (please note that type and Name are different), e.g. c_tbUserEmail for a TextBox into which the user should type in his/her e-mail. I find it useful because when there are a lots of a controls, it can be hard to find them in the miles long intellisense list, so by adding the c_ prefix I can easily see all controls in that form.

---

This Hungarian/VB6-naming insanity needs to stop.

If Microsoft really wanted you to name your controls based on their type then why doesn't Visual Studio automatically tack on the 'txt' or 'btn' when you add the control to your web/win Form?

---

I use Hungarian notation, that makes easy to find controlls in large pages.

---

For the elements that I don't plan on using in my code, I just let the designer handle it for me; if they do become something used in my code, they're changed to something meaningful and that happens to be descriptionType (nameTextBox). It's how the designer creates them if given enough information (check out menu items -- "Exit" becomes exitMenuItem).

---

My own practice is: Type _contextDescriptionType. E.g.:

TextBox _searchValueTextBox

Anyway naming convention is either too personal or imposed by general rules. In any case it should be documented somewhere so that all project developers can easyly access.

---

You have the Guidelines for Names from Microsoft. I dot not follow everything, but it's a good starting point

---

I believe naming convention exist to ease the developer coding effort and helps in manageability. To my understand any name which is helpful in easy access should be followed.

I saw number of comments with different approach but the best i found in my projects are to prefix control's 1st three name. There are lots of reason behind following this approach.

1. Intellisense would bring all same type together.
2. Form property windows would also show all same control sorted
3. On complex forms you can easily identify you are dealing with label or textbox (eg. lblAccounts and txtAccounts)
4. A new user can easily deal with coding.
5. Imagine I have accountLst, accountlbl, accounttxt, accountgrd, accountChk controls on same form.

While coding, a developer always knows he is accessing text box or label. Where as he is not clear with what name the other developer has used. So by just writing "lbl" intellisens would bring all the label list to choose, where is if you have used approach used in #5 then intellisense would bring all controls using acc. I rarely saw doing some loop with control name start with "account" or so. This means it would not help in any rare incident.

My bet is to do things which help in understanding code easily for other developer. Because as you grow up in your carrier, you would not always do coding, some other person would come and take your seat.

Choice is yours, which way you want!

---

If there is a good separation of concerns in an application design, I guess there will be no need for naming buttons as LoginButton, LoginBtn or btnLogin. If the owner of the object is a UI element thus let's call it Login and if the owner is not a UI element then the object is in a wrong place.

참고URL : https://stackoverflow.com/questions/1246546/best-practices-for-c-sharp-gui-naming-conventions