努力不使用匈牙利符号

我见过支持和反对匈牙利系统的争论。多年来，我一直在使用该系统的旧项目上工作，方法是命名每个变量，并使用变量类型的前缀（例如（strName，intAge，btnSubmit等））进行命名（我知道原始的匈牙利应用前缀是变量，而不是类型）。我希望我的下一个项目完全放弃它，但是我确实发现很难不借助它来唯一地命名类似的东西。

可以说我有一个用于收集电子邮件地址并将其存储在数据库表中的网络表单，还有一个按钮，它调用了将地址保存到数据库的函数。

如果我使用的是匈牙利风格符号，则可以将该框txtEmail称为按钮，btnEmail并将其称为textbox中包含的值strEmail。然后，我可能会使用一个功能storeEmail(strEmail)来存储电子邮件。我这里有一个明确的约定，很明显每个变量是什么。

命名这些变量的最佳实践是什么

• 不求助于匈牙利系统
• 而不会使它们长时间或令人困惑
• 并在整个项目中使用明确的约定？

最后一点是最重要的-无论您做什么，都需要在整个项目中以及与同事保持一致。实现一致性的主要方法有两种，如果可能，应同时使用两种方法。首先使用工具在构建时检查命名约定。在.Net世界中，StyleCop将是此类工具的一个很好的例子。获得一致性的第二种方法是对所有代码进行同行评审，以便所有人都可以保持警惕。

您的其他两点似乎在询问替代方案。我不确定您是否需要替代方案；关于匈牙利语不再流行的要点是，当类型系统和工具稍微严格一点时，它曾经被用来描述类型。也就是说，如果您使用C语言进行编程，并且传递指针来跟踪该类型，则唯一的方式就是使用匈牙利语。现在，如果您使用的是C＃或Java之类的语言，则不会使用指针（或很少使用），因此不再需要任何匈牙利语。另外，现代IDE可以通过将鼠标悬停在变量上来轻松查看类型，或者在最坏的情况下使用一些快捷方式来查看原始声明。因此，我认为您不需要任何表示法，只需按变量的功能命名即可。如果是电子邮件地址，请使用“电子邮件”或“

在处理Web表单/ Windows表单/其他图形对象时，使用Systems Hungarian是有意义的，因为您可以将控件紧密地绑在一起，例如，文本框和标签可以放在一起。您可以命名它们txtEmail并lblEmail加以区别。以我的经验，这很普遍并且实际上很有用。

但是在您的代码隐藏中，这种命名是不必要的。如果您有一个string用于存储电子邮件的类型变量，只需将其命名email。如果由于某种原因感到困惑，则大多数IDE应该允许您将鼠标悬停在它上面并查看其类型。（理想情况下，在面向对象的东西中，它可能是某个对象的属性，并且user.Email更加清楚。）

我认为，如果您在代码中声明了多个对象，而该对象不是可以正确命名的GUI控件，email则设计中固有存在问题。

是什么使变量“长期”？

相反的txtEmail，btnEmail你可以使用UserEmailText，UserEmailButton和AdminEmailText，AdminEmailButton

问题是您可能开始感到变量开始变长：

AdminEmailIsValid 我开始对变量允许的时间进行区分。

此外，您可能会开始注意到正在重用一组变量以及对这些变量的一组操作。这就是OOP的目的。创建一组通用对象，而不是一组变量：

class EmailForm
  var textBox, button, text
  function storeEmail()

然后，您可以将一个新变量实例化为一个类，并使用相同的点符号来访问数据：

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

当然，这是针对使用OOP范例的语言的，但是大多数流行的Web开发语言都是面向对象的，或者允许使用面向对象的代码（PHP，Python，C＃，C ++，Java，JavaScript，ActionScript等） ）。