WPF UI 元素命名约定

Question

尽管 Hungarian notation 现在被认为是不好的做法，但在用户界面元素的名称中对类型进行编码仍然很常见，可以使用前缀(lblTitle、txtFirstName、...)或后缀(TitleLabel、FirstNameTextBox、... )。

在我的公司，我们也这样做，因为它使由同事(或很久以前由您自己)编写的代码更易于阅读(根据我的经验)。通常反对这样做的论点——如果类型改变，你必须改变变量的名称——不是很强大，因为改变 UI 元素的类型通常需要重写代码的所有部分，如果它被引用的话.

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

编辑:我知道通过数据绑定(bind)，命名 UI 元素的需求减少了。然而，有时它是必要的，例如在开发自定义控件时...

Answer 1

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

在我看来，最大的缺点是，我写了很多 ui 代码是匈牙利语使错误更难被发现。如果您尝试更改文本框上的选中属性，编译器通常会选择它，但它不会选择以下内容:

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 中可能无关紧要，但我认为应该始终避免使用匈牙利语。