Question

所以我看到了很多不同的编码风格，但我只会谈两个大的编码风格。我使用一种风格，在一般意义上使用时，我只是将它们命名为类名，如下所示：

String str = "This is some text";

但是在Java Practices处，我看到一种样式，他们会在Interfaces类名称前加上'I'，或者在对象名称前加上'f'或'a'。从"Don't subclass JDialog or JFrame"'获取此代码段：

/**
  Constructor.

  <P>Called when adding a new {@link Movie}.
*/
MovieView(JFrame aParent) {
    fEdit = Edit.ADD;
    buildGui(aParent, "Add Movie");
    fStandardDialog.display();
}

程序员为什么要用这种风格编码？有很多人使用它吗？而且，专业程序员是否也使用这种风格？

提前致谢：）

Answer 1

这是我个人的意见。

我不想在接口上使用前缀（或其他任何内容）。我只是喜欢称之为它。接口用于表示对象（或其中的一部分），而不会对其实际实现产生任何影响。

假设你有一个Car界面。而AudiA4可能是该车的实现。如果你刚买了一辆新的奥迪A4，你会说“我买了一辆新的AudiA4”给那些你认为关心你购买的汽车的人。对于其他人，你可以说“我买了一辆新车”。当然，你永远不会说，我买了一个新的IAudiA4或一个新的ICar。

JFrame命名是因为它是一个Swing Frame而Swing是在AWT（原始的Java窗口工具包，已经有一个Frame类）之后出现的。由于AWT和Swing同时可用，因此他们使用'J'前缀来划分工具包（注意JFrame扩展了Frame，顺便说一下）。他们可以称之为SwingFrame，但'J'前缀显然是代表Swing包的一个很好的选择。所以基本上这个前缀只是一个命名选择，而不是类似于'I'用于interfance的约定（或者你有时看到的实现的Impl后缀）

我的观点是，您必须根据它们所代表的内容为您的类和界面命名。不多也不少。没有一点CarImpl类。谁在乎它是一个实现。它的实现方式是什么？为什么需要自己的课程？使用CarImpl时我还能得到什么？当我进行第二次实现时会发生什么，我称之为CarImpl2？这一切都非常有限，并没有带来多大价值。

称它为它。这是我提出的唯一规则。

所有这一切，Eclipse项目以及许多其他项目确实使用I-for接口表示法（WIKI）。但这是他们的选择。我见过专业人士也使用它。我不喜欢它，但总的来说，我尊重团队的命名惯例。

Answer 2

有一本关于此类事情的书 - 史蒂夫麦康奈尔的代码完成

Answer 3

我可能错了，但我在命名Java变量时遇到的唯一普遍约定是使用Camel-Case表示法，即关于名称的格式。

至于名称本身，我总是觉得有用的是根据实际的名称来命名变量。在你的String示例中，尽管你提到这将是一个通用变量，我仍然会给它一个更有意义的名称，如：

String message = "This is some text";

或者：

String msg = "This is some text";

我看到的一些Java库在命名变量时往往非常冗长，其他的只是在变量用于缩减的上下文时使用单个字母名称：

public Rectangle setLocation(Point p) {
    return setLocation(p.x(), p.y());
}

我认为命名变量（或其他任何事情）的主要目标始终是以尽可能最好的方式与您尝试做的事情进行沟通。

Answer 4

你所描述的有时被称为“匈牙利符号”，尽管它不是真正意义上的“匈牙利语”。

基本上，我们的想法是区分不同类别的变量 - 实例变量，局部变量，参数等。这有两个基本目的：

它有助于避免名称冲突，例如，自然地（使用“描述性”变量命名）可能是实例变量ralphsLeftFoot和局部变量ralphsLeftFoot。使用前缀允许两者共存，特别是在本地可能（没有警告消息）“隐藏”实例变量的语言中，防止这种冲突中语义的意外更改。
它使变量的范围变得明显，因此，在维护期间，人们不会意外地假设局部变量具有实例范围，反之亦然。

这种方法值得吗？许多开发人员使用该方案的一个子集，显然效果很好。例如，许多Objective-C开发人员将实例变量命名为具有前导“_”字符的“属性”，以明确区分这两者，并避免在预期属性时意外使用实例变量。

同样，许多语言的许多开发人员都会在实例变量前加上一个字母（通常是“m”），以区别于“普通”的本地/参数变量。

最重要的是选择你（和你的团队）喜欢的风格并坚持下去。如果团队喜欢前缀，那么使用前缀。如果团队更喜欢其他东西，请坚持下去。当然，改变偏好，当一个更好的选择被“透露”给你时，是可以的，但不要随便来回切换。

Answer 5

代码样式有助于开发人员更轻松地阅读和理解彼此的代码。 Java conventions规定使用简短和描述性标识符，但不幸的是，短篇和描述性并不总是能够一起实现，因此您可能不得不为了清晰而妥协：atmosPres - 仍然清晰而短暂，{{1} } - 这不容错误，atmosphericPressure - 因为每个人都知道ATM，对吗？atm - WTF？

我首先遇到了在C＃中开发程序时使用三字母类型标识符为变量名称添加前缀的做法 - 它有助于读者知道变量中包含的数据类型，而无需查找其声明（由于内存不足或也许是懒惰？）。数组也以ap为前缀，例如I，以区别于其他数据类型（出于何种目的，我只是不知道）。

对我来说，最糟糕的代码约定是在C ++中（如果确实存在任何问题） - 数据类型和变量的案例类型，冲突的方法和函数命名样式以及无穷无尽的隐秘缩写都会使它变得困难对于非常规C ++编码器来阅读和理解C ++代码。

Answer 6

所以我看到了很多不同的编码风格，但我只会这样做   谈论两个大的。我使用的风格我只是命名一切   比如在一般意义上使用它们的类名，如：

String str =“这是一些文字”;

太糟糕了。想象一下，如果有人在阅读您的代码，试图理解它在做什么，并且他们遇到了一个名为str的变量。对于必须阅读此代码的人来说，这并没有任何意义。

用户可以使用约定来提高可读性，从而提高软件的整体质量。如果没有约定，任何拥有多个开发人员的项目都会遇到不同的样式，这只会损害代码的可读性。如果您想了解专业人士的工作，请在互联网上查看各种conventions。

关于Java代码样式的问题

6 个答案: