Question

虽然Hungarian notation现在被认为是不好的做法，但通过使用前缀（lblTitle对用户界面元素的名称进行编码仍然很常见，txtFirstName，...）或后缀（TitleLabel，FirstNameTextBox，...）。

在我的公司，我们也这样做，因为它使得同事（或很久以前自己）编写的代码更容易阅读（根据我的经验）。这个参数通常提出反对这样做 - 如果类型改变，你必须改变变量的名称 - 不是很强，因为改变UI元素的类型通常需要重写代码的所有部分，无论如何它被引用

所以，我正在考虑在开始WPF开发时保持这种做法（嗯......我们应该使用TextBlocks或TextBoxes的txt前缀吗？）。我错过了什么大的劣势？这是你说“不要这样做，因为......”的机会。

编辑：我知道通过数据绑定，名称UI元素的需求减少了。然而，有时需要，例如，在开发自定义控件时......

Answer 1

就个人而言，我发现WPF在这方面改变了规则。通常，您可以在很少或没有代码的情况下逃脱，因此使用前缀来区分名称会使事情变得更加混乱而不是更加混乱。

在Windows窗体中，每个控件都在代码中按名称引用。使用大型UI时，半匈牙利语符号很有用 - 它更容易区分您正在使用的内容。

但是，在WPF中，这是一个需要名称的罕见控件。当您必须通过代码访问控件时，通常最好使用附加属性或行为来执行此操作，在这种情况下，您永远不会处理多个控件。如果您正在使用UserControl或Window代码隐藏，我只使用“标题”和“名称”而不是“txtTitle”，特别是因为现在您可能只会处理一些有限的控件，而不是所有这些。

在大多数情况下，即使自定义控件也不需要名称。您将需要遵循约定的模板名称（即：PART_Name），但不是实际的x：UI的名称元素......

Answer 2

根据我的经验 - 在WPF中，当您更改控件的类型时，除非您做错了什么，否则通常不必重写任何代码。实际上，大多数情况下，您不会在代码中引用控件。是的，您最终会这样做，但WPF中对UI元素的大多数引用都是由同一个XAML中的其他元素引用的。

就个人而言，我发现“lblTitle，lblCompany，txtFirstName”比“Title”更难阅读。我没有.intWidth和.intHeight（再见lpzstrName！）。为什么有.lblFirstName？我可以理解TitleField或TitleInput或其他更多内容，因为它描述的是什么，而不是如何描述。

对我来说，希望有这种类型的分离通常意味着我的UI代码试图做太多 - 当然它正在处理UI元素，它在窗口代码中！如果我不处理围绕UI元素的代码，为什么我会在这里编写代码呢？

Answer 3

我喜欢使用约定（一般来说只是一个好主意），但对于UI的东西我喜欢它在前面有控件的类型，后面是描述性名称 - LabelSummary，TextSummary，CheckboxIsValid等。

听起来很小，但首先放置类型的主要原因是它们会一起出现在Intellisense列表中 - 所有标签在一起，复选框等等。

Answer 4

即使从Winforms的角度来看，我也不喜欢半匈牙利人。

我认为最大的缺点是，我写了很多ui代码，因为匈牙利人更容易发现错误。如果您尝试更改文本框上的checked属性，编译器通常会选择它，但它不会选择以下内容：

lblSomeThing.Visible = someControlsVisible;
txtWhatThing.Visible = someControlsVisible;
pbSomeThing.Visible = someControlsVisible;

我发现调试起来更容易：

someThingLabel.Visible = someControlsVisible;
whatThingTextBox.Visible = someControlsVisible;
someThingPictureBox.Visible = someControlsVisible;

我还认为将addCommentsButton与addCommentsTextBox分组比将btnAddComments与btnCloseWindow分组要好得多。你什么时候打算一起使用最后两个？

就找到我想要的控制而言，我同意Philip Rieck的看法。我经常想要处理与特定逻辑概念相关的所有控件（如标题或添加注释）。我几乎从不想找到碰巧在这个控件上的任何或所有文本框。

这可能与WPF无关，但我认为应该始终避免使用匈牙利语。

Answer 5

同意其他答案，主要是个人偏好，最重要的是保持一致。

考虑到数据绑定的普遍性，根本不需要命名......您可能想要考虑的一件事是您的UI是否经历过自动化测试。像QTP之类的东西通过Name找到应用程序中的可视元素，因此编写测试脚本的自动化工程师会非常欣赏像标签，按钮等（任何交互式控件）这些都被很好地命名的。

Answer 6

在WPF中，您几乎不需要（甚至不想）为控件命名。因此，如果您正在使用WPF最佳实践，那么为您的控件命名无关紧要如果您有理由为其命名。

在极少数情况下，您确实希望为控件命名（例如，对于ElementName =或TargetName = reference），我更喜欢根据名称的用途选择一个名称，例如：< / p>
<Border x:Name="hilightArea" ...> ... <DataTrigger> ... <Setter TargetName="hilightArea" ...

Answer 7

我在任何用户界面名称前加上两个下划线，如__所示，因此在调试时它会在其他属性之前排序。当我需要使用IntelliSense查找控件时，我只需输入__并显示控件列表。这继续了为单个下划线添加前缀到模块级变量的命名约定，如int _id;中所述。

Answer 8

您可以使用官方Microsoft网站获取Visual Basic 6控件命名约定，也可以将其与推荐的C＃命名约定结合使用。它非常具体，被C＃中的开发人员广泛用于控件名称，并且仍然可以在WPF或Windows Forms上下文中使用。

Visual Basic 6控件命名约定：Object Naming Conventions

C＃推荐的命名约定：General Naming Conventions

WPF UI元素命名约定

8 个答案: