在java中创建_names_of_fields_like_these有什么问题？

发布于 2024-08-25 09:21:34 字数 165 浏览 3 评论 0原文

有时我会看到这样的事情：

class Clazz {

   private int _goodName;

   private int _anotherGoodName;

   ...
}

我不明白。阅读这样的代码既困难又不寻常。有什么优点？

原文

From time to time I see something like this:

class Clazz {

   private int _goodName;

   private int _anotherGoodName;

   ...
}

I don't get it. It's hard and unusual to read such code. What are the pros?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

北恋 2024-09-01 09:21:34

这是一些人用来表示“这些是私有变量”的命名约定。

就我个人而言，我不是粉丝，因为我认为你可以省略下划线并获得相同的结果，但每个人都有自己的结果。我认为它可能起源于 IDE 出现之前的时代，当时您可能正在查看一个方法，并且某些变量的可见性/所有权并不总是清晰的。

回复收藏 0 原文

冷了相思 2024-09-01 09:21:34

我见过的带有下划线前缀的成员和方法的示例使用约定来指示当您无法将其设为私有时，您不应触及该成员或方法。我把它读作“这里有龙”，我自己从来没有理由使用它。

一个示例是 _jspService() servlet 开发中的方法。查看链接的 JavaDocs。

回复收藏 0 原文

萌化 2024-09-01 09:21:34

这只是一个偏好问题。有些人喜欢在类的所有私有成员变量中添加“_”，而其他人则不喜欢。我个人不喜欢它，但又是偏好。

回复收藏 0 原文

鸢与 2024-09-01 09:21:34

命名约定都是关于编写代码的人如何舒适地阅读/复制（尽管它们应该是关于每个人都容易阅读的内容）

我有一个朋友使用这个约定以及诸如：

private int m_myVariable;

对于他的所有字段等。它表示它是您正在查找的特定类的成员，但如果您不这样做，那么读起来会非常烦人。

Naming conventions are all about what's comfortable for the person writing the code to read/replicate (though they should be about whats easy for everyone to read)

I have a friend who uses this convention along with something like:

private int m_myVariable;

for all of his fields etc. It denotes it as a member of the particular class you're looking in but it gets very very annoying to read if you don't do the same.

回复收藏 0 原文

壹場煙雨 2024-09-01 09:21:34

如果您可能有一个成员变量、属性和参数都引用同一事物的情况，那么区分是非常有意义的：

private string _myVariable;
public MyClass(string myVariable)
{
    //do stuff.
    _myVariable = myVariable;
}

public string MyVariable
{
    get
    {
         return _myVariable;
    }
}

If it is a likely scenario that you could have a member variable, a property and a parameter all refer to the same thing, it makes perfect sense to distinguish:

private string _myVariable;
public MyClass(string myVariable)
{
    //do stuff.
    _myVariable = myVariable;
}

public string MyVariable
{
    get
    {
         return _myVariable;
    }
}

回复收藏 0 原文

束缚ｍ 2024-09-01 09:21:34

我曾经在代码中使用这些约定：

非最终静态字段以下划线开头。

私有静态 SomethingOrOther _goodName;

参数以下划线结尾。

public void doSomething(Object goodParam_, String stringToo_) {
}

虽然您可能认为很难阅读变量的声明，但关键是要确保在阅读使用它们和的代码时它们弹出确保它们始终不同于任何非静态字段、参数和本地定义的变量。

我认为，这样的标准的另一个好处是，当其他人来修改代码时，他们可以快速识别静态字段和参数，这使得更容易理解代码，而不必总是引用定义。

我通常不考虑实例字段的约定，因为对它们的访问几乎完全是通过 s/getters 进行的。

我已经不再使用 Java 代码，而是更喜欢让我的 IDE 始终使用 this 完全限定实例字段，使用类名指定静态字段，并始终使用 final 每个不变的变量，甚至是方法参数。走这条路的有趣之处在于，它鼓励良好的命名实践，至少对我来说是这样，因为我喜欢我的变量在带有 this 前缀或类名时能够很好地阅读。

I used to use these conventions in my code:

Non-final, static fields begin with an underscore.
```
private static SomethingOrOther _goodName;
```

Parameters end with an underscore.

public void doSomething(Object goodParam_, String stringToo_) {
}

And while you may consider it hard to read in the declaration of the variable, the point is to make sure they pop when reading the code in which they're used and to ensure that they are always different than any non-static fields, parameters and locally defined variables.

Another benefit of standards like this, i think, is when others come along to modify the code, they can quickly identify static fields and parameters which makes comprehension of the code happen more readily rather than having to always refer back to definitions.

I don't generally consider a convention for instance fields because access to them is almost exclusively through s/getters.

I've moved away from this with Java code, preferring instead to have my IDE always fully qualify with this for instance fields and with the class name for static fields and always using final on every variable that doesn't change, even method parameters. The interesting thing about going this route is that it encourages good naming practice, at least for me, because i like my variables to read nicely when prefixed with this or the class name.

回复收藏 0 原文

~没有更多了~