团队内部冲突的Java样式

我是Java开发团队的一员，截止日期为6周。这需要非常非常快地编写大量代码。但是，我们的开发团队具有不同的编码风格。从名称约定到抽象方法的所有内容在我们的团队中都不同。有人知道任何指示Java“标准”的文件吗？

为了澄清，我想知道是否有一个组织会规定例如变量和函数的正确命名约定。这是至关重要的，因为在如此短的期限内，我们不能花时间尝试理解彼此的代码。

有这样一个组织：Sun / Oracle本身。该文档称为Java编程语言的代码约定，它描述了您需要的大多数约定。只要所有人都同意阅读并遵循其建议即可。

我真的在安德烈斯（Andres）的答案上贴上标签，并专注于统一格式化Java代码的方面。

如果使用的是Eclipse，则可以将其Java格式化程序设置为自动格式化为Java标准。Eclipse格式化程序还具有其他有用的设置，例如每行字符（即，在换成新行之前每行有多少个字符）以及许多其他设置。每行的字符标准化使比较不同开发人员编写的代码更加容易，而没有空格和换行符之间的很大差异。

最后，使用Eclipse，在完成所需的所有设置后，将格式化程序导出为文件，团队中的每个成员都可以导入。因此，如果您使用的是Eclipse，我强烈建议您全面研究它将自动为您格式化和代码编辑的所有选项，然后与整个团队共享设置。

我假设其他主要的Java IDE（IntelliJ和Netbeans）具有导出格式设置的类似功能。

这种[不同的编码样式]是至关重要的，因为在如此短的截止日期之前，我们不能花时间尝试理解彼此的代码。

其实。这不是最重要的。

担任顾问30年后，我从许多客户那里阅读了很多代码。重要的是要注意，每个客户（通常在客户组织内）都有不同的样式。

阅读了很多样式后，我学到了这一点。

风格不重要

请专注于编写始终有效的代码，并编写证明其始终有效的单元测试。

交付有效代码后，如果没有足够的错误修复和安装增强功能，则可以对其进行修饰。

不必担心选择一些完美的通用标准。您所需要做的就是让您的团队同意一项标准并坚持下去。如果需要，请自己化妆，但要保持一致。

一致性改善了协作，协作改善了代码。

即使实际的一致性没有帮助，但您的团队共同努力达成协议这一事实也是一件好事。他们无法同意像编码约定这样简单的内容，这表明可能存在更大的团队合作问题。

上面提到的Sun Java CC不仅已有13年的历史，并且其中一些规则已经过时（例如每行80个字符），而且除了最通用的命名约定（类的大写字母，大写大写字母）之外，它没有定义命名约定。用于静态最终变量等）。

您需要为不同类型的类（例如DAO，EJB，实体）定义自己的标准，无论使用什么。Sun Java CC就像一个抽象基类，意在扩展:)

就像其他人在这里提到的那样，您可以在线搜索Java的几种流行“样式指南”之一，并说服团队中的每个人坚持使用它们。您最喜欢的IDE中的一些代码检查工具可能会在您不这样做时提醒您。

但是，有时涉及政治。我曾经遇到过这样一种情况：即使有人提到需要标准化，团队中最资深的开发人员仍会继续这样做。在这种情况下，观察他的代码风格并跟随他可能会更好，因为他可能最了解代码库和要求，并且即使他很困难，您也不想浪费时间踩他的脚趾。这是我们其他人在特定情况下所做的，我很不情愿地遵循。

因此，考虑您的情况也很重要。

鲍伯叔叔在他的《清洁代码》一书中展示了一种更现代和最新的编码风格。不幸的是，它不包含任何项目列表。您必须阅读它。他对自己说，要了解他的约定，您必须阅读他的代码。鲍勃叔叔无疑是一个机构。无论如何，这本书都是一本非常好的书，所以即使现在为时已晚，也请尽快阅读。

在代码中真正重要的是较低的循环复杂度，较小的范围，较高的内聚性和表达标识符的选择。有了这些，代码就变得易于掌握，并且这样的代码很好。

我建议您研究Spartan编程。

大多数编码标准都告诉您如何使写得不好的代码看起来漂亮，并且大多数有关“编码样式”的讨论实际上都是关于格式化的。代码格式化是关于可视地表示您的代码结构。它是琐碎且可自动化的，几乎没有任何代码风格，因为编码风格与您如何表示代码结构无关，而与代码结构有关。
关于命名约定，也有很多宗教战争，尽管实际上，它们只是解决不良设计的工具。一个名字很好，只要能说明它的意思。范围越小越清晰，选择这样的名称就越容易。