用于在代码隐藏中引用的 UI 控件命名约定的最佳实践？
在表单和报告中命名 UI 控件（文本框、下拉列表等）以供代码隐藏页面中参考的最佳实践是什么？
我在办公室制作大量报告和表格。 我有几个 Web 应用程序，提供大约 80 多个“实时”报告，这些报告是从各种和多个数据源（Access、SQL、Oracle）生成的。 这些报告被认为是“实时”的，因为它们接受来自表单的用户设置参数，然后查询数据库以根据当前可用信息生成报告。
因此，该过程首先获取用户设置的值，将这些值传递给数据库查询，接收数据集，最后将数据集分配给报表。 在某些情况下，在生成报告之前，需要根据数据集计算报告上显示的其他字段。 这需要引用报告上的输出控件来分配计算值。
虽然我不太关心在代码中为变量或成员字段使用前缀，但我确实使用它们来标识 UI 控件。 例如，txtFirstName 引用报表控件，将数据集中 FirstName 字段的数据分配给报表上的显示控件。 在表单和报表上命名/引用 UI 控件是否有更好的做法？
What is the best practice for naming UI controls (textboxes, drop-downs, etc.) on forms and reports for reference in the code-behind pages?
I develop a lot of reports and forms in my office. I have several web applications providing about 80+ "live" reports being generated from various and multiple data sources (Access, SQL, Oracle). These reports are considered "live" because they accept user set paramaters from a form, then query the database to produce a report based on the current information available.
So, the process starts with obtaining the values set by the user, passing those to the database query, receiving the dataset, and finally assigning the dataset to the report. In some cases, additional fields displayed on the report need to be calculated from the dataset before the report can be generated. This requires referencing the output controls on the report to assign the calculated value.
While I don't really care to use prefixes in my code for variables or member fields, I do use them to identify the UI controls. For example, txtFirstName to reference the report control to assign the data from the FirstName field in the dataset to the display control on the report. Is there a better practice for naming/referencing UI controls on forms and reports?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我更喜欢的 iOS UI 组件的 2 字符前缀：
bt_:UIButtonlb_：UILabeltx_：UITextFieldtv_：UITextViewvw_:UIViewim_：UIImageViewsc_：UIScrollViewtb_：UITableViewcl_：UICollectionViewst_：UIStackViewpk_：UIPickerViewpr_：UIProgressViewai_：UIActivityIndicatorViewwb_：UIWebView / WKWebViewmp_：MKMapViewgr_：UIGestureRecognizersw_：UISwitchsl_：UISlidersp_：UISteppersg_：UISegmentedControlpg_：UIPageControldp_：UIDatePicker2-char prefixes for iOS UI components I prefer:
bt_:UIButtonlb_:UILabeltx_:UITextFieldtv_:UITextViewvw_:UIViewim_:UIImageViewsc_:UIScrollViewtb_:UITableViewcl_:UICollectionViewst_:UIStackViewpk_:UIPickerViewpr_:UIProgressViewai_:UIActivityIndicatorViewwb_:UIWebView / WKWebViewmp_:MKMapViewgr_:UIGestureRecognizersw_:UISwitchsl_:UISlidersp_:UISteppersg_:UISegmentedControlpg_:UIPageControldp_:UIDatePicker我一直认为前缀的唯一真正原因是这样您可以在同一表单/页面上包含 txtFirstName 和 lblFirstName 之类的内容。 因为绝大多数时候，我实际上只使用实际的字段控件本身，所以我跳过了前缀，而只使用关联控件的前缀。 例如，lblMonth & 月份，跳过 cbo 前缀。
它可以节省打字时间，并且通常很明显您在此类表单中使用的是哪种控件。 更复杂的控件将得到完整的前缀处理。
I've always felt that the only real reason for the prefixes was so you could have things like txtFirstName and lblFirstName on the same form/page. Since, the vast majority of the time, I'm really only working with the actual field control itself, I skip the prefix for that, and only use the prefixes for associated controls. For instance, lblMonth & Month, skipping the cbo prefix.
It saves typing, and it will generally be obvious what sort of control you're using in such forms. More complex controls will get the full prefix treatment.
我也和你做类似的事。 当您有大量控件时，一切都会变得混乱，因此我在每个名称前加上控件类的大写字母。
例如：
文本框-> tbName
数据网格 -> dgName
面板 -> pName
这使得清楚如何处理新控件（即如何导出前缀）
I do similarly to you. When you have tons of controls it all becomes messy, so I prefix each name with the capitals of the control class.
For example:
TextBox -> tbName
DataGrid -> dgName
Panel -> pName
This makes it clear how to handle new controls (i.e. how to derive the prefix)
我仍然对控件使用匈牙利表示法，但不再对变量使用。
I still use Hungarian Notation for Controls but no longer for variables.
您在这里的答案将非常主观。 不同的品味和编程背景会给你不同的偏好。
从长远来看，也许对您来说最重要的是所有项目之间的一致性，这样无论谁开发了代码，您在阅读时都能够理解它。
我们外包很多，因此请务必将我们的命名约定传达给所有项目经理。
以下是一些命名约定的链接：
http://www.irritatedvowel.net/Programming/Standards。 aspx
http://msdn.microsoft.aspx com/en-us/library/xzf533w0(VS.71).aspx
http://www.visualize.uk.com/resources/asp-net-standards.asp
Your answers here will be very subjective. Different tastes and programming backgrounds will give you different preferences.
Perhaps what will be most important to you in the long run is consistency among all of your projects, so that regardless of who developed the code you will be able to understand it when reading.
We outsource a lot, so make certain to communicate our naming conventions to all of our project managers.
Here are some links to naming conventions:
http://www.irritatedvowel.net/Programming/Standards.aspx
http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx
http://www.visualize.uk.com/resources/asp-net-standards.asp
对于 GUI 控件，我在变量名称后加上控件名称的后缀：
这使得 _firstName 和 firstNameTextBox.Text 之间的关系变得显而易见，并且没有人必须记住等效的匈牙利表示法是什么。 在命名变量时，我总是选择清晰而不是简洁。
For GUI controls, I suffix the variable name with the control name:
This makes the relationship obvious between for example _firstName and firstNameTextBox.Text, and no one has to remember what the hungarian notation equivalent is. I would always choose clarity over brevity in naming variables.
我在工作中开发的主要产品使用 txt_ pnl_ 等前缀。 这确实有效，尽管有时将隐藏/显示控件的内容从 tr 切换到面板时会有点痛苦，因为您必须重命名它。
我在新项目中开始做的是使用 ui 前缀命名我的 UI 控件； 例如，uiName。 由于我强烈反对反匈牙利符号，并争取自文档化代码，这个公约运作良好。 事实上，如果有的话，它是真正的匈牙利表示法（ui 是表示用户界面控制的前缀）。
The main product I work on at work uses the txt_ pnl_ etc prefixes. This does work, though it is a bit of a pain at times when switching something that just hides/shows controls from say, a tr to a panel because you have to rename it.
What I've started doing in new projects, is naming my UI controls with a ui prefix; for example, uiName. Since I am strongly opposed to anti-hungarian notation, and strive for self-documenting code, this convention works well. In fact, if anything, it is real hungarian notation (ui being the prefix meaning user interface control).