关于Java代码风格的问题

所以我看到了很多不同的编码风格，但我只会谈论两个大的代码风格。我用一种风格，我仅举一切都像他们的类名在一般意义上使用时，这样的：关于Java代码风格的问题

String str = "This is some text";

但随着在Java Practices，我看到一种风格，他们会加上一个“我”在前面接口类的名称，或者他们把'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(); 
}

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

感谢提前:)

来源

2012-08-04 mattbdean

灯罩坏[匈牙利命名法]的（http://en.wikipedia.org/wiki/Hungarian_notation）的做法。我认为这种记号最令人fr目。 – 2012-08-04 19:43:11

如果你写一个事实，你有一个问题，你应该把问题本身置于主题中。 – 2012-08-04 19:43:16

@HovercraftFullOfEels哦真的吗？我不知道。感谢您的链接。 – mattbdean 2012-08-04 19:46:03

这是我个人的意见。

我不喜欢在接口（或其他任何其他方面）上使用前缀。我只是喜欢称它为什么。接口意味着代表一个对象（或其中的一部分），而不会对它的实际实现产生任何影响。

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

JFrame命名是因为它是一个Swing Frame和Swing来自AWT（原始的Java窗口工具包，它已经有一个Frame类）之后。既然AWT和Swing同时可用，他们使用'J'前缀来划分工具包（注意JFrame扩展Frame，btw）。他们可以称它为SwingFrame，但'J'前缀显然是表示Swing包的一个好选择。所以基本上这个前缀只是一个命名选项，而不是类似于'I'的惯例（或者你有时也会看到Impl后缀）

我的观点是你总是必须根据你的类名和接口来命名正是他们所代表的。没有更多，不少。没有CarImpl类的要点。谁在乎这是一个实现。它是什么实现？为什么它需要自己的班级？当我使用CarImpl时，还能得到什么？当我做第二次实现时会发生什么，我称之为CarImpl2？所有这些都非常有限，并没有带来太多的价值。

称它为什么。这是我提出的唯一规则。所有这一切，Eclipse项目确实使用I-for接口表示法（WIKI）。但这是他们的选择。我也见过专业人士使用它。我不喜欢它，但总的来说，我尊重团队的命名习惯。

来源

2012-08-04 19:51:18 mprivat

哇，谢谢你的细节。这有助于很多:) +1 – mattbdean 2012-08-04 19:54:53

我从来没有理解许多人选择在Java的实现类中使用'Impl'后缀，当有'Bean'后缀时。 'CarBean'读得比'CarImpl'好得多（除非你不是Java编码器，那么bean和番茄酱）甚至可以用名字空间来区分实现的名称和后缀，例如'public interface Car { ...} - 接口，公共类CarBean实现Car {...} - 实现。 – 2012-08-04 21:09:24

-1

所以，我已经看到了很多不同的编码风格，但我只打算谈两个大的。我使用一种风格，我只是将其所有的名称命名为，就像它们的类名一般使用时一样，如下所示：

String str =“This is some text”;

这太可怕了。想象一下，如果有人在阅读你的代码，试图了解它在做什么，他们遇到了一个名为str的变量。它没有传达任何意义的人必须阅读此代码的意图。

约定被人们用来提高可读性，从而提高软件的整体质量。没有约定，任何拥有多个开发人员的项目都会受到不同风格的影响，这只会影响代码的可读性。如果你想知道专业人士做什么，在互联网上浏览各种conventions。

来源

2012-08-04 19:48:39

“我用一种风格，我仅举一切都像他们的类名**在一般意义上**使用时，” – mattbdean 2012-08-04 19:55:36

是什么意思，甚至？ – 2012-08-04 20:00:10

OP关心评论你的投票吗？ – 2012-08-04 20:05:28

有一本关于这样的东西的书 - 史蒂夫麦康奈尔代码完成

来源

2012-08-04 19:50:24 evg

@whowantsakookie：这本书恰好是关于代码构建的哲学和实践的最好书籍之一，也是我最喜欢的编程书籍之一，你不会后悔阅读，也不会后悔。你可能想重新考虑你的评论。 – 2012-08-05 03:38:48

@HovercraftFullOfEels好的，但我的评论去了哪里？：\我知道这是一本好书，但那不是我所期待的。 – mattbdean 2012-08-05 17:06:23

@whowantsakookie：版主必须删除您的评论。坦率地说，这有点粗鲁。 – 2012-08-05 17:07:19

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

我THI当命名变量（或其他任何事情）时，主要目标总是以尽可能最好的方式与你正在尝试做的事情进行交流。

来源

2012-08-04 20:00:08

我完全同意你的看法。就像当你创建一个'BufferedReader'时，你不会把它叫做'br'，你可以把它叫做'saveFileLoader'或类似的东西。 – mattbdean 2012-08-04 20:02:12

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

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

这有助于避免名称冲突，在那里，说，有可能自然（使用“描述性”的变量命名）是一个实例变量ralphsLeftFoot和局部变量ralphsLeftFoot。使用前缀可以使两者共存，特别是在本地可能（没有警告消息）“隐藏”实例变量的语言中，可以防止意外的语义变化与这些冲突无关。
它使变量的范围显而易见，因此，在维护期间，不会意外假定局部变量具有实例范围，反之亦然。

这种方法值得吗？许多开发人员使用该方案的一个子集，显然取得了良好的效果。例如，许多Objective-C开发人员会将实例变量命名为具有前导“_”字符的“属性”，以明确区分这两者，并避免意图在属性意图时使用实例变量。同样，许多语言的开发人员都会在实例变量前添加一个字母（通常为“m”），以区分它们与“正常”本地/参数变量。

可能最重要的是选择一种你（和你的团队）喜欢并坚持的风格。如果团队喜欢前缀，则使用前缀。如果球队喜欢别的东西，坚持这一点。当然，改变偏好时，当向你“透露”一个更好的选择时，是可以的，但不要无情地来回切换。

来源

2012-08-04 20:08:12

谢谢，我通常会在更高范围的变量中看到前缀。这解释了很多。 +1 – mattbdean 2012-08-04 20:23:54

如果您在编程Java，您应该坚持使用通用的Java编码风格，该风格不含匈牙利符号。 – 2012-08-04 20:38:14

没有“常见的Java编码风格”。 – 2012-08-04 20:51:39

代码风格有助于使开发人员更容易阅读和理解对方的代码。 Java conventions规定使用短和描述标识符，但不幸的是简短的描述并非总能实现在一起，所以你可能不得不妥协急促的清晰度，因此：atmosPres - 仍不清楚，但总之，atmosphericPressure - 这不能被误认为，atm - 因为每个人都知道ATM，对吗？，ap - WTF？

我第一次遇到在C＃中开发程序时用三字母类型标识符给变量名加前缀的做法 - 它帮助读者知道变量中包含的数据类型，而不必查找它的声明（由于内存短或者懒惰？）。器件还与I e.g IList前缀从其他数据类型区分开来（出于什么目的，我只是不知道）。

对我来说，最糟糕的代码约定是在C++中（如果确实有这些约定的话） - 数据类型和变量的案例类型混合，方法和函数命名风格冲突以及无穷无尽的缩写都使得它很难让非常规的C++编码人员阅读和理解C++代码。

来源

2012-08-04 20:57:24

我同意你的意见。妥协只能采取一定的水平。 +1 – mattbdean 2012-08-04 20:59:35

关于Java代码风格的问题

回答

相关问题