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

#1 楼

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

我想在项目中强制采用单一代码格式的两个主要原因。首先与版本控制有关：每个人都以相同的格式设置代码，保证文件中的所有更改都有意义。不再只是在此处或此处添加或删除空间，更不用说将整个文件重新格式化为实际上只改变一两行的“副作用”了。第二个原因是它需要程序员的自我超越。由于每个人都以相同的方式格式化他们的代码，因此您再也无法轻易分辨出谁写了什么。该代码变得更加匿名和共有，因此没有人会为更改“别人的”代码而感到不安。我感到很欣慰的是，我不必费心思考代码格式，因为保存时Eclipse会自动为我完成。它是无忧无虑的，就像使用LaTeX编写文档一样：它是格式化后的，您在编写时不必担心。我还参与了每个人都有自己风格的项目。然后，您必须考虑一些愚蠢且毫无意义的问题，例如是否可以按照自己的样式修改其他人的代码，还是应该尝试模仿他们的样式。我可以针对您的情况想到的唯一的反对通用代码格式设置的参数是，它显然已经在进行中，因此它将在所有文件中造成许多不必要的更改，从而破坏了实际的文件历史记录。最好的情况是，您可以从项目开始就立即开始执行设置。

#2 楼

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

许多软件开发人员都进行过福音战争…… 。在这种情况下，最好不要开始...

#3 楼

是的，为所有开发人员提供一种代码格式样式是一件好事。

设计代码样式格式并将其导入所有Eclipse开发人员。 merging代码输入到“版本控制”系统。

#4 楼

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


代码的常见外观确实可以帮助提高代码的可读性，但如果错误，也会使事情变得更糟外观和感觉。 _hUngarian_lpfstr表示法是一个主要示例：）
我已经看到“代码标准”强制注释块之间的空格数量，方法名称的字母顺序以及其他废话。不要那样做。
不同的语言有不同的标准，人们会习惯使用它们的经验。有些甚至强制执行这些标准（认为Python，Cobol，Visual Studio自动强加C ++样式支撑约定，而Java通过约定使用C样式等）。仅以这种方式引入新问题。这意味着代码段以及整个源文件。因此，当有人在1000行文件中更改一行时，不要重新格式化现有代码。对自动批准系统或审阅者“看起来正确”。他们也会养成编写干净代码的习惯，仅仅是因为这是可行的，即使它们的自然风格之间存在细微的差异。强加特定的样式和标准，有充分的理由不严格地这样做。

#5 楼

是的，出于其他人提到的原因，一致性是一个好主意。 > Oracle已经发布了一组Java约定，这是事实上的标准。公共库和开放源代码项目倾向于使用这些约定，因此当您需要查看这些约定时，应该很熟悉格式。 />

您可能要考虑在源代码管理设置中构建一个挂钩，以便代码在进入主分支之前自动格式化。


您可以避免与特别顽固的拒绝遵循标准的程序员的斗争。他们甚至可以在工作时使用自己的格式，稍后将对其进行标准化！
如果最终使用了自定义格式设置（例如，很多人忽略了“每行最多80个字符”的约定），则只需在一处进行更改。

#6 楼

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

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

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

（消除代码异味比保持一致的格式更为重要。这是自动化工具的好处。）施加相同的格式，并更多地鼓励相似的外观。而且，当您放牧猫时，自动化工具可以帮助提高技能并减少代码异味，而不会伤及脆弱的自我。

#7 楼

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

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

个人偏好只是这样，很少会提高产量：https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

并完成工作。

#8 楼

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



机器在最坏的时间（通常是在您使用新语言功能时）出错。它将如何处理Java等中的闭包？ Jalopy在使用具有成员函数的枚举时遇到麻烦。我发现提到这是在“此处”格式化代码的方式很有帮助，而不是在所有地方都应格式化所有代码。他们以前的公司可能选择了其他途径，没关系。与本地语言不同，您想要带出一些特定于您的代码文化的习惯用法。
最好通过代码审查来加强代码语法：

如果格式化很重要，那么它会吸引您的组织进行代码审查。这是一个巨大的好处。
如果违反了格式化规则，则如果意图传达得更加清晰，则与机器相比，人可以查看并判断得更好。这非常罕见，但偶尔会发生。
关于“可读性=>生产率”，代码结构（例如单一职责类和函数）将为您带来更多收益比代码格式化更快。代码格式化可能会有所帮助，但是不同的人对语句的解析方式有所不同-并非每个人都会“更有效率”。我想在格式上加倍考虑代码结构，因为这也会使您着手进行代码审查，并促使团队思考程序的工作原理，而不是单个循环的外观。 />我不是Domain Driven Design的忠实拥护者，但它是一个最近的模型，它对如何构造代码以及代码格式化惯例自然地从Domain Driven Design结构化程序中产生了非常清晰的定义。再说一次...我不喜欢DDD，但这是一个很好的例子，因为它定义的很好。

我想这个答案的主题是，对代码进行回顾，让格式从文化和超出审核流程。

#9 楼

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

我从来没有见过一套可以在所有情况下都提高可读性的代码格式化规则。同样，英语中也没有100％适用的语法规则：我们的大脑就不是那样。因此，请使用准则，但给予开发人员自由选择的权限，以便他们认为合适。

但是请记住，格式化对可读性的贡献远不只是代码的逻辑组织简单。我已经看到很多无法理解的意大利面条式代码，而且格式都非常完美！

#10 楼

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

在我从事的一个特定项目中，根本没有约定。每个开发人员都以自己的方式做事。由于该团队的相对经验不足，因此从一个班级转到下一个班真的很不高兴。与命名约定问题相比，样式不是问题。一位开发人员会以可怕的匈牙利符号（在现代IDE时代是一种愚蠢的做法）引用UI元素，一个会以一种方式命名私有成员，另一种会以不同的方式命名它们。您只是不知道自己在看什么。相反，一个团队在其构建过程中使用了StyleCop（这是一个.Net项目）。更糟糕的是，他们还使用了大多数默认规则。因此，您将在行距或大括号位置方面做一些完全正常的事情，因此构建会因此而呕吐。仅在内容上添加空格和线条就浪费了很多时间，并且每个人，包括坚持使用StyleCop的家伙，最终几乎每次提交都要做。这是时间和金钱的极大浪费。

所以我在这里要说的是，僵化不是答案，但在狂野西部也不是答案。真正的答案是找到最有意义的地方，在我看来，这应该是没有自动化的工具来检查内容的方法，但也不是违背约定俗成的。

#11 楼

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

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

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

希望这种编码风格将使原始编码器难以区分，并防止自我战争在最佳情况下是胡扯，而在最坏情况下则是愚蠢的。优秀的程序员无论样式如何，总是会产生优美的代码。在代码中开发整个单元并对其负责，这使开发人员对自己的工作感到自豪，并阻止开发者开发笨拙的代码，因为他们知道错误会再次被猎杀。

编码风格始终假定将选择他自己的编码风格，其他所有人都将遵循。想象一下，您最不喜欢所有合作开发人员喜欢的编码样式被选为标准。您是否仍然坚持采用编码风格？

#12 楼

一种规则来统治所有人...真的是最佳选择吗？

就像驾驶别人的汽车...

确保您可以开车上任何一辆汽车，如果您花时间根据自己的喜好调整座椅，方向盘和后视镜，则将更安全，更舒适且不会撞车。

使用代码，格式化确实会影响您的阅读舒适度并理解代码。如果与您习惯的相距太远，则需要更多的精力。

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

自动执行需要付出一定的代价：

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

有时存在解决这些问题的方法，但是与如何防止自动格式化程序对代码进行处理相比，开发人员还有更多重要的事情要注意。运用常识。

#13 楼

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

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

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

就这样。

#14 楼

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

#15 楼

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

Google发表了一篇有关此文件的文章，名为“搜索构建债务：
在Google管理技术债务的经验”。

#16 楼

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

#17 楼

我会说不是。在团队中使用通用的代码结构/格式绝对是一件好事，但自动执行则不是。

我的最大问题是


如果我以一种格式编写代码，那是自动重新格式化后，实际学习该格式会有什么动力？
在上一点之后，如果您不学习该格式，则自动格式化的整个要点（使代码更易于阅读和修改）完全消失了。在阅读代码时，您仍然需要花一些时间来弄清楚格式，因为您还没有学会过该格式
我认为作为开发人员一天写一个课程，关闭它，然后第二天返回，发现情况完全不同。这意味着不仅其他人必须学习您的代码，还必须学习您的代码。
这也可能鼓励惰性编码。他们不必强迫开发人员学习格式，而是可以在阳光下以任何格式编写文字，它会自动看起来像其他所有人想要的格式。回到第二点，您无法学习样式，但仍然无法正确读取样式。

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

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