对所有开发人员强加相同的代码格式是一个好主意吗？

我们正在考虑在我们的项目中采用单一标准代码格式（在Eclipse中具有保存操作的自动格式）。原因是，当前有几个（> 10）开发人员使用的代码格式存在很大差异，这使一个开发人员更难处理另一开发人员的代码。相同的Java文件有时会使用3种不同的格式。

因此，我认为优点很明显（可读性=>生产率），但是强加此方法是个好主意吗？如果没有，为什么？

更新
我们所有人都使用Eclipse，并且每个人都知道该计划。大多数人已经使用了一种代码格式，但是由于某些人倾向于坚持自己的代码格式，因此未强制执行。由于上述原因，有些人宁愿执行它。

我目前在一个强制执行标准代码格式并在保存文件时自动格式化代码的地方工作，就像您将要做的那样。作为公司的新成员，我发现通用的格式化规则给我一种温暖而模糊的感觉，即“这些家伙知道他们在做什么”，所以我再也不会高兴了。;）作为相关说明，使用通用格式设置规则，我们还在Eclipse中强制执行了某些相当严格的编译器警告设置，其中大多数设置为Error，许多设置为Warning，几乎没有设置为Ignore。

我想说有两个主要理由在项目中强制采用单一代码格式。首先与版本控制有关：每个人都以相同的方式设置代码格式，可以保证文件中的所有更改都是有意义的。不再只是在此处或此处添加或删除空格，更不用说将整个文件重新格式化为实际上只改变一两行的“副作用”。

第二个原因是，它使程序员的自我观念摆脱了困境。由于每个人都以相同的方式格式化他们的代码，因此您再也无法轻易分辨出谁写了什么。该代码变得更加匿名和共有，因此没有人会为更改“别人的”代码而感到不安。

这些是主要原因，还有其他原因。我感到很欣慰的是，我不必费心思考代码格式，因为保存时Eclipse会自动为我完成。它是无忧无虑的，就像使用LaTeX编写文档一样：它是在以后格式化的，因此您在编写时不必担心。我也曾在每个人都有自己风格的项目中工作。然后，您必须考虑一些愚蠢且毫无意义的问题，例如是否可以按照自己的样式修改其他人的代码，或者是否应该尝试模仿他们的样式。

我可以针对您的情况想到的唯一的反对通用代码格式设置的参数是，它显然是一个已经在进行中的项目，因此它将在所有文件中造成许多不必要的更改，从而破坏了实际的文件历史记录。最好的情况是，您可以从项目开始就立即开始执行设置。

出于您概述的原因，每个专业软件开发人员都更愿意采用（良好）标准，而不是为风格而进行福音战争。

许多软件开发人员进行福音战争……

根据您在团队中的职位和团队动态，您可能决定无法赢得战争。在这种情况下，最好不要开始...

是的，对于所有开发人员来说，拥有一种代码格式样式是一件好事。

设计代码样式格式，然后将其导入所有开发人员。

当我们merging编写“版本控制”系统代码时，这将有所帮助。

您想要获得什么，您将如何对肛门进行保持（在详细程度上将列出“规则”），您是否打算对使用不同语言编写的代码进行实施，您要尝试在现有代码上追溯实施吗？

1. 通用的外观确实可以帮助提高代码的可读性，但是如果外观和感觉错误，也会使情况变得更糟。_hUngarian_lpfstr表示法是一个很好的例子:)
2. 我已经看到“代码标准”强制注释块之间的空格数量，方法名称的字母顺序以及其他废话。不要那样做
3. 不同的语言有不同的使用习惯，人们会习惯使用这些语言。有些甚至要求使用这些标准（例如，Python，Cobol，Visual Studio自动强加C ++样式支撑约定，而Java按约定使用C样式等）。
4. 永远不要为了更改代码而更改现有代码，而只是以这种方式引入新问题。这意味着代码段以及整个源文件。因此，当有人更改1000行文件中的单行时，请勿重新格式化现有代码。
5. 如果经验丰富的程序员不必半天思考自己编写的内容是否对自动批准系统或审阅者“看起来正确”，那么他们可以提高生产力。他们也会养成编写干净代码的习惯，只是因为这是可行的，即使它们的自然风格之间存在很小的差异。

因此，尽管有充分的理由强加特定的样式和标准，但也有严格的理由不强加。

是的，一致性是一个好主意，原因他人已经提到。

我只想添加一些其他地方没有使用的要点：

• Oracle已经发布了一组 Java 约定，这是事实上的标准。
  • 使用这些应该有助于避免关于要遵循的样式的争论。
  • 许多公共图书馆和开放源代码项目都倾向于使用这些约定，因此当您需要查看这些约定时，应该熟悉其格式。
  • Eclipse格式化程序具有内置规则来匹配这些约定，这也应该有所帮助。
• 您可能要考虑在源代码控制设置中建立一个挂钩，以便代码在进入主分支之前自动格式化。
  • 您可以避免与特别顽固的拒绝遵循标准的程序员的战斗。他们甚至可以在工作时使用自己的格式，稍后将对其进行标准化！
  • 如果最终使用了自定义格式设置（例如，很多人忽略了“每行最多80个字符”的约定），则只需在一个地方进行更改。

我所在的团队使用了Checkstyle插件。我们没有使用开箱即用的功能，而是成立了一个由感兴趣的开发人员组成的小型委员会。我们就似乎缺少的东西，似乎过度的东西进行了辩论，并敲定了一切。我们都在此过程中学到了一些东西，并增强了开发人员的肌肉。

（我们的决策示例：宽度为72个字符太小，但是120个字符更好；使用_ALLCAPS进行静态结局更好；从函数中强制一次退出是一个好主意。）

当我们进行代码审查时，第一个问题是：“您是否通过Checkstyle运行了它？” 遵守编码标准在很大程度上是自动化的，这使注意力从审阅者的挑剔中移开了。让Checkstyle突出显示方法签名，右键单击并将变量更改为final十分容易。它还可以修复缩进和花括号，以便每个人的代码都具有相似的外观。缺少用于公共功能的Javadoc吗？Checkstyle将标记该功能。

（消除代码异味比保持一致的格式更为重要。这是自动化工具的好处。）

我会把诸如Checkstyle之类的自动化工具放在不强加相同格式的位置，而更多地放在鼓励相似外观上。而且，当您放牧猫时，自动化工具可以帮助提高技能并减少代码异味，而不会伤及脆弱的自我。

如果您要坚持使用同一个IDE并合并一些格式化工具，那么这是个好主意，因为您不需要太多的工作。保持规则简单，侧重于可读性而不是肛门保持性。那应该是量尺。

尽管始终如一的格式的泥球比仅仅一个泥球好，但您最好将时间花在清理它上，而不是对托架的位置太挑剔。不要变成头脑呆板的经理，他觉得自己在通过在代码检查过程中计算缩进空格并确保新的封面在TPS报告中来完成工作。

个人喜好仅此而已，很少能改善生产：https : //stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

如果是这样，那就克服它并做点事情。

我强烈建议人们强制执行代码格式设置，并且细微地忽略或轻描淡写。简而言之，其原因是

1. 在最坏的时间，通常是在使用新的语言功能时，机器会出错。它将如何处理Java等中的闭包？Jalopy在使用成员函数枚举时遇到麻烦。
2. 我认为，请程序员为公司提供类似于公司代码的代码是非常合理的负担。我发现提到这是在“此处”格式化代码的方式很有帮助，而不是在所有地方都应格式化所有代码。他们以前的公司可能选择了其他途径，没关系。与本地语言不同，您想要带出一些特定于您的代码文化的习惯用法。
3. 最好通过代码审查来实施代码语法：
   1. 如果格式化很重要，那么它将吸引您的组织进行代码审查。这是巨大的好处。
   2. 如果格式化规则被破坏，则如果意图传达得更加清晰，则与机器相比，人可以查看并做出更好的判断。这是非常罕见的，但偶尔会发生。

关于“可读性=>生产力”，代码结构（例如单一职责类和函数）将为您带来比代码格式化更快的速度。代码格式化可能会有所帮助，但是不同的人对语句的解析方式有所不同-并非每个人都会“更有效率”。我想在格式上加倍考虑代码结构，因为这也会使您着手进行代码审查，并促使团队考虑程序的工作原理，而不是单个循环的外观。

我不是Domain Driven Design的忠实拥护者，但它是一个最近的模型，它对如何构造代码以及代码格式化惯例自然地从Domain Driven Design结构化程序中产生了非常清晰的定义。再说一次……我不喜欢DDD，但这是一个很好的例子，因为它定义的很好。

我想这个答案的主题是，进行代码审查，并让格式从文化中流出来，并退出审查过程。

通常，假设您雇用了合理的开发人员，则强加通用代码格式是个坏主意。但是，采用代码准则是一个好主意。

我从未见过一套可在所有情况下均能提高可读性的代码格式化规则。同样，英语中也没有100％适用的语法规则：我们的大脑就不是那样。因此，请使用准则，但要让开发人员自由选择适合的准则。

话虽这么说，“遵循文件/项目中已经存在的代码约定”这一较难的规则是一个很好的规则。

但是请记住，格式化对可读性的贡献远不只是代码的逻辑组织简单。我见过很多无法理解的意大利面条代码，带有完美的格式！

我认为对此没有简单的答案。这不是一个是或否的问题。尽管我认为样式和命名约定在一定程度上很重要，但是浪费太多时间思考它也很容易。最好以身作则。

在我从事的一个特定项目中，根本没有约定。每个开发人员都以自己的方式做事。由于该团队的相对经验不足，因此从一个班级转到下一个班级确实很令人讨厌。与命名约定问题相比，样式不是问题。一位开发人员会以可怕的匈牙利符号（在现代IDE时代是一种愚蠢的做法）引用UI元素，一个会以一种方式命名私有成员，另一种会以不同的方式命名它们。您只是不知道自己在看什么。

相反，一个团队将StyleCop（这是一个.Net项目）用作其构建过程的一部分。更糟糕的是，他们还使用了大多数默认规则。因此，就行距或大括号放置而言，您将执行完全正常的操作，因此构建会因此而呕吐。仅在内容上添加空格和线条就浪费了很多时间，并且每个人，包括坚持使用StyleCop的帅哥，最终几乎每次提交都这样做。这是浪费大量的时间和金钱。

所以我在这里要说的是，僵化不是答案，但是在狂野西部也不是答案。真正的答案是找到最有意义的地方，在我看来，这是没有自动化的工具来检查内容的方法，也不是让风向标。

我反对通用编码风格的主要观点是，有经验的程序员习惯于阅读自己的风格。您可以训练手来书写特定的样式，但是几乎不可能训练眼睛来理解您讨厌的样式。程序员编写一次代码，然后在开发和调试期间一次又一次地读取代码。如果每次他阅读自己的代码，由于被迫以BAD风格编写代码而使他难以理解，那么他将感到非常不高兴且工作效率降低。这是根据我的经验。

我对Eclipse不太熟悉，但是在保存声音时自动格式化听起来像一个可怕的想法。开发人员必须完全控制自己的代码，无论是否强加了编码风格。未经用户明确同意，“保存”操作不得更改单个字符。

如果您的公司出售源代码，则编码风格更为重要，但是如果您出售已编译的代码，则其相关性将大大降低。

希望这种编码风格将使原始编码器难以区分，并防止自我战争在最好的情况下是胡扯，而在最坏的情况下是愚蠢的。优秀的程序员总是会生成优雅的代码，无论其样式如何。

我也极力支持让每个开发人员拥有特定代码单元的所有权，并反对让所有人自由接触每段代码。在代码中开发整个单元并对其负责，这使开发人员对自己的工作感到自豪，并阻止开发人员开发出糟糕的代码，因为他们知道错误会再次吸引他。

最后，任何具有专业编码风格的人都始终假设自己的编码风格将被选中，其他所有人都将遵循。想象一下，所有合作开发人员中最不喜欢的编码样式被选为标准。您仍然赞成采用编码风格吗？

一种统治所有人的格式...真的是最佳选择吗？

就像开别人的车...

当然，你可以跳在和驾驶任何汽车，但你会更安全，更舒适，而且不容易，如果你花时间来调整座椅，方向盘和后视镜崩溃您的偏好。

使用代码，格式化确实会影响您阅读和理解代码的舒适度。如果与您习惯的相距太远，则需要更多的精神努力。是否有必要将其强加给开发人员？

+1到目前为止提到的所有好处，但是...

自动执行需要考虑以下成本：

-1表示代码格式化人员不了解代码格式化的美感。您有多少次代码格式化程序破坏了以表格形式正确对齐的注释块？您故意以某种方式将一个复杂的表达式对齐以提高可读性，而只是让自动格式将其格式化为“遵循规则”，但可读性却低得多的次数？

有时，这些问题有解决方法，但是与如何防止自动格式化程序破坏代码相比，开发人员需要考虑的是更重要的事情。

有格式规则，但可以自由运用常识。

好的开发人员是富有创造力的人，请给他们一些艺术许可。“保持简单”应该是程序员的口头禅。我有两个规则：

规则1：提供变量/游标/对象/过程/任何敏感名称。明确的名称为您的代码带来含义和理解。

规则2：使用缩进显示代码的结构。

而已。

对我来说，自动应用通用格式的主要优点是它可以帮助我们进行更改跟踪和代码审查。git（和大多数其他源代码管理工具）可以显示文件以前版本的差异。通过强制使用通用样式，可以最大程度地减少程序员的偏好差异。

样式指南还可以简化用于各种分析目的的程序化代码解析。

谷歌已经发表了一篇名为《寻找建筑债务：谷歌管理技术债务的经验》的论文。

语言不是代码。我们人类有6000多种语言，因此我们会翻译它们。因此，如果您希望您的“代码”进行交流，则必须进行调整。您会看到我们用户必须更改数据格式，因此我们不会丢失数据。

我会说不是。在团队中使用通用的代码结构/格式绝对是一件好事，但自动执行则不是。这应该由人来完成，而不是由计算机来完成。

我对这个概念最大的疑问是

1. 如果我以一种格式编写代码，并且该代码会自动重新格式化，那么有什么动力可以真正学习该格式？
2. 在上一点之后，如果您不学习格式，则自动格式化的整个点（使代码更易于阅读和修改）完全丢失了。在阅读代码时，您仍然需要花一些时间来弄清楚格式，因为您还没有学过这种格式
3. 我认为，作为开发人员，有一天写一堂课，关闭它，然后第二天返回，发现它是完全不一样的，这对开发人员来说是一种痛苦的经历。这意味着不仅其他人必须学习您的代码，而且还必须学习您的代码。
4. 它也可能鼓励惰性编码。他们不必强迫开发人员学习格式，而是可以在阳光下以任何格式编写内容，并且它将自动看起来其他所有人都希望使用该格式。这可以回到＃2，在这里您不会学习样式，但仍然无法正确阅读它。

现在，我可能倾向于说，在一个全部完成的项目上运行自动格式化将是一个好主意。当您以后要修复/添加功能时，这将使每个开发人员从同一步骤开始。但是，在积极发展中，我认为这是一个非常糟糕的选择。

基本上：把责任放在员工身上，以学习公司的风格，不要强迫他们的代码成为事实。