趋势网(微博)讯：Java开发人员 Stijn Geukens和10名开发人员一起工作，几乎每位开发人员都有自己的风格。而情况即将有所不同了，因为公司可能很快开始规定所有开发人员使用统一的代码格式。他们将使用Eclipse（跨平台的自由集成开发环境）来促进这场改变。可是，强制使用统一代码格式的规定到底是弊还是利呢？会不会带来更多的麻烦？

请跟随趋势网海外译者的视角一起来看看以下大腕的观点：

杂技演员高空坠落 直播间千人目睹 羊毛月一夜掉粉近22万 高中同学曝羊毛月文化成绩倒数 肇庆一殡仪馆用炖盅当骨灰瓮 吴柳芳账号被禁止关注

专业化

ZeroOne回答：

我目前工作的地方强制我们使用标准代码格式，在保存文件时代码会自动格式化，就像你们准备实施的规定那样。作为公司的一位新成员，我发现，统一格式化规则给我的感觉是，“这些家伙知道他们在做什么”。除了统一格式化规则，我们在Eclipse环境中也强制使用一些相当严格的编译器警告设置，大多数设置是“错误”，有很多是“警告”，但几乎没有“忽略”这个设置。

我想说，在项目中使用统一代码格式主要有两方面的原因。

首先是跟版本控制有关的：大家都统一代码格式化，那么可以保证所有文件都是有意义的。再也不会仅仅在这里或哪里添加或删除一个空格，更不会因为仅仅改变一两行的“副作用”就重新格式化整个文件。

第二个原因是，这样做在某种程度上可让程序员在写等式时不再以自我为中心。大家的代码都统一格式化了，不能再像以前那样很容易就分辨出谁写了什么。代码成为了不分你我的共同财产，因此没有人再因为改变“别人的”代码而感到不安。

还有其他的原因可以说明统一代码格式是最佳的办法。我觉得很欣慰的是，我不用再费心思去考虑我的代码格式，当我保存时Eclipse会自动统一格式，就像用LaTeX写文档（写完后会自动格式化）那样无所挂虑了。我也试过和别人一起完成项目，大家的风格迥异，然后你就必须得考虑一些繁琐的问题，比如，按自己的风格来修改别人的代码好不好？或者，你是否应该试着模仿别人的风格来进行修改呢？

统一代码格式设置的唯一反对理由就是，对于你这种情况，也就是对于一个正在进行的项目，我想这样做会导致所有文件发生很多不必要的变化，搞乱了实际的文件历史记录。最佳的做法应该是，项目一开始就开始使用一致的格式。

一致性

Baqueta回答：

没错，鉴于其他人所说的原因，一致性确实是一个好主意。我只想补充说明几点还谈到的内容：

甲骨文软件公司已经公布了一套Java惯例，那些惯例都属于事实标准。

运用这些惯例应该可以帮助你避免跟随哪种风格的争论。公共图书馆和很多开放资源项目往往都会使用这些惯例，所以当你需要查看时，格式化应该是熟悉的。此外，Eclipse的格式化程序已内置匹配这些惯例的规则，也应该会很帮助。

你可能想考虑在源代码控制设置中建立一个钩子，从而让代码在进入主区之前就自动格式化。

你可以避免和那些特别顽固、不肯按照标准来的程序员进行争论。他们在工作的时候甚至都可以完全按照自己的风格，只是这些风格最后会标准化而已！如果你不再使用自定义格式设置（例如，很多人忽略了“每行最多80个字符”的惯例），那么你只需要在一个地方进行更改。

人人参与

rajah9回答：

我现在的团队在用CheckStyle（检查源文件编码规范）插件。并非直接使用里面的解决方案，我们让感兴趣的开发人员组成了一个小型委员会。我们思考和讨论哪些内容看似是缺乏或多余的，然后决定并搞定。在这个过程中，我们都学到了一些东西，提高了开发人员的能力。（我们的决定就像这些例子：72个字符宽太小了，120个更好；使用_ALLCAPS作静态结尾更好一点等等）

当我们进行代码审查，其中的第一个问题是：“你让它通过CheckStyle运行了吗？”符合编码标准主要都是自动化的，而会让挑剔的审查人员注意力分散。通过CheckStyle来突出方法标记、单击右键并改变结尾变量是相当容易的。它也可以处理缩进和括号，让大家的代码看起来和感觉起来都是差不多的。