1

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

String str = "This is some text";

但是在Java Practices中，我看到了一种风格，他们会将“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();
}

为什么程序员以这种风格编写代码？很多人用吗？而且，专业程序员会使用这种风格吗？

提前致谢 ：）

4

6 回答 6

3

这是我个人的看法。

我不喜欢在接口上使用前缀（或其他任何东西）。我只是更喜欢称它为它是什么。接口旨在表示一个对象（或它的一部分），而不会对它的实际实现产生任何影响。

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

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

我的观点是，您总是必须根据它们所代表的确切名称来命名您的类和接口。不多也不少。没有 CarImpl 类。谁在乎它是一个实现。它是哪个实现？为什么它需要自己的类？当我使用 CarImpl 时，我还能得到什么？当我进行第二个实现时会发生什么，我称之为 CarImpl2？所有这些都非常具有约束力，并没有带来太多价值。

叫它什么。这是我制定的唯一规则。

话虽如此，Eclipse 项目和许多其他项目确实使用了 I-for 接口表示法 ( WIKI )。但这是他们的选择。我也见过专业人士使用它。我不喜欢它，但总的来说，我尊重团队的命名约定。

于 2012-08-04T19:51:18.763 回答
1

有一本关于这些事情的书——Steve McConnell 编写的 Code Complete

于 2012-08-04T19:50:24.947 回答
1

我可能错了，但我在命名 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());
}

我认为命名变量（或与此相关的任何其他内容）时的主要目标始终是尽可能以最佳方式传达您尝试做的事情的意图。

于 2012-08-04T20:00:08.410 回答
1

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

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

  1. 它有助于避免名称冲突，比如说，自然可能（使用“描述性”变量命名）有一个实例变量ralphsLeftFoot和一个局部变量ralphsLeftFoot。使用前缀允许两者共存，并且，特别是在本地可能（没有警告消息）“隐藏”实例变量的语言中，可以防止此类冲突导致语义发生意外更改。
  2. 它使变量的范围显而易见，因此，在维护期间，人们不会意外地假设局部变量具有实例范围，反之亦然。

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

同样，许多使用多种语言的开发人员会在实例变量前面加上一个字母（通常是“m”），以将它们与“普通”局部/参数变量区分开来。

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

于 2012-08-04T20:08:12.193 回答
1

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

I first encountered the practice of prefixing variable names with a three letter type identifier while developing programs in C# - it helps the reader know what data type is contained in a variable without having to look for its declaration (due to short memory or maybe laziness?). Arrays are also prefixed with I e.g IList to distinguish them from other data types (and for what purpose, I just dunno).

For me, the worst code conventions are in C++ (if indeed there are any at all) - there's a mix of case types for data types and variables, conflicting method and function naming styles and endless cryptic abbreviation which all make it hard for non-regular C++ coders to read and understand C++ code.

于 2012-08-04T20:57:24.690 回答
-1

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

String str = "这是一段文字";

那太可怕了。想象一下，如果有人正在阅读您的代码，试图了解它在做什么，并且他们遇到了一个名为str. 它不会向必须阅读此代码的人传达任何关于您的意图的意义。

人们使用约定来提高可读性，从而提高软件的整体质量。如果没有约定，任何拥有多个开发人员的项目都会受到不同风格的影响，这只会损害代码的可读性。如果您想了解专业人士的工作，请在互联网上四处寻找各种惯例。

于 2012-08-04T19:48:39.813 回答