java变量名

你能给出一些很好的理由让类名成为任何变量名的一部分吗？我们过去有这个政策，我觉得很有用。一些团队成员希望恢复决策

我目前的论点是：

• 你可以直接知道你在说什么：
  用于（学生：学生）{ ... }

很容易理解（与学生或任何学生相比）

• 它有助于对代码进行自我注释
• 我们的ide为此提供了直接支持
• 你可以直接看到你是用苹果而不是梨（或熊；-）

在细微差异重要的地方减少混淆：

criteriaBuilder.equal(nameExpression, name);

我能看到的唯一反对这一点的理由是，它使代码变长了（我认为这在现代IDE中不是问题）

是否有针对此类建议的公开规定？有人用同样的规则吗？有其他选择吗？

听起来很像

原则上这听起来是个好主意，但我真的不确定有什么好的理由：

• 自我注释/记录代码-这应该是可能的，而无需在变量名中添加类型
• IDE还应该支持查看变量的类型，而无需将其放入变量名中（例如Eclipse可以这样做）
• 我不知道这真的是一个优势

匈牙利符号的一个问题是，如果重构代码，还必须更改所有的变量名。在日常WTF中有很多例子，其中变量被命名为“strSOMETHING”或“intSOMETHING”，即使类型被定义为其他类型

总的来说，我认为使用匈牙利符号的理由是站不住脚的，一般来说，我不建议将其作为一项政策

---

（如果这不是你所说的，我很抱歉！）

你在这个问题上的圣经是Steve McConnel的书，，这是关于这样的软件构建实践的最全面的书。他有一整章关于变量命名以及为什么它很重要

关键是要使名称成为变量作用的完整描述，以便阅读它的人容易理解。如果它做到了这一点，那就是良好的实践

Student看起来像一个简单易懂的策略，但它有一个直接的缺点-它不包含关于变量的额外信息。你已经知道他是个学生了。如果您知道关于对象的任何其他信息，请将其添加到变量名中-studentUnderReview、graduatingStudent等。只有在您完全不知道其他信息（例如，该变量用于迭代所有学生）时，才应使用“student”。现在，在长方法中，只需查看名称就可以知道类型，但是如果变量的作用域较短，那么它是否有用就无关紧要了。有一些研究（见McConnel）表明，对于范围非常短的变量，例如循环索引，短名称更好

---

只要你有两个变量，这个系统就会崩溃。如果默认值是将一个变量称为“student”，那么诱惑就是将两个变量称为“student1”和“student2”，这确实是一种糟糕的做法（有关详细信息，请参见McConnel）。你需要用名字来描述这个对象——好学生和坏学生；studentBeingSaved和studentBeingRead。

策略应使用描述性变量名。单字母变量名是不好的，但完全基于类名的变量名也是不好的。您的主要参数实际上是用于描述性变量名

至于其他方面：

• 它有助于对代码进行自我注释-不，它从变量声明中复制信息
• 我们的ide对此提供了直接支持——只有在替代方案没有任何好处的情况下，这才是一个论点
• 你可以直接看到你用的是苹果而不是梨（或者熊；-）-这就是类型系统的工作

当然，如果您的类名是描述性的，那么有时使用相同名称的变量是有意义的——当变量描述类的实例时，没有任何明显的特征。如您的示例所示：

for (Student student: students) { ... }

---

如果你对所有的学生进行循环，这很好。但是，如果您有一个非泛型的

Student

，变量名应该描述学生在程序的这一部分中所扮演的特定角色（例如

candidate

或

graduate

）。

通常，您的变量名应该帮助开发人员快速了解它们实际代表的是什么。

Student-Student

如果定义的关系表示任何与学生的关系，例如

Student[/code>（或者更好的一些学生集合）对于类
教授
或类似的人来说都是可以的

String
通常是个坏主意，因为它没有说明该变量的使用。更好的名称应该是
字符串名称
、
字符串描述
或类似名称。在某些情况下，重要的是处理的是一个字符串，就像一般的字符串实用程序一样，可以调用变量
string
，但如果有两个或更多，则应使用更好的名称（例如
源代码
和
目标代码>等，具体取决于类/方法）

IMHO，如果添加前缀/后缀可以告诉您一些关于变量的信息，而其基本名称不会告诉您，那么添加前缀/后缀可能是一个好主意，例如，在web环境中，您可以处理用户输入的字符串以及转义字符串（例如，为了防止代码注入），因此，您可以使用前缀/后缀在用户输入版本和转义版本之间进行区分
 您应该命名变量，以便清楚它们包含/表示的内容。类型通常不重要。例如，您是否愿意编写
String=“Eric”
？否