我应该期望编程团队遵循严格的编码标准吗？

Question

我个人非常支持在与开发人员团队合作时遵循内部编码标准。我认为这将使代码连贯，并允许人们更轻松地扩展代码库、切换工作并互相协助解决难题。

另一方面，我知道有很多人认为只要编码能按时完成且正常运行，我们就应该接受各自编码风格的不同之处。

看到这两种情况，我很难决定是否值得限制程序员的风格，以换取（有时是微小的，有时是巨大的）拥有符合标准的代码库所获得的好处。特别是在敏捷开发框架内工作时，速度至关重要，我认为这变得更加重要。

为了加剧情况，我是一名PHP程序员，因此你很少会见到两个编码者具有相同的风格，因为它在很大程度上是一个自学的学科。

应该采用宽松的标准作为建议，只强制执行非常重要的项目（例如限制变量名称中的匈牙利命名法），还是应该铁腕要求缩进必须是制表符而不是空格，并且花括号始终位于它们自己的行上？

编辑：

我应该在问题中看到我的错误——我想知道标准应该有多严格——它们应该有很大的自由度还是应该严格限制？

- Shane

---

从我的回答中可以看出：你严格要求的就是标准。因此，如果你不打算“严格”执行，那么你就没有标准。话虽如此，按照“标准”方式命名、缩进和放置大括号所需的时间与非标准方式相同。我认为你的标准应该是任何让你感到必须应用才能满意的东西。 - Liz Albin

我完全同意你所说的--但我也关心团队士气和让人们感到受到压制，因为他们要求改变长期以来的习惯，因为我的（或其他程序员的）风格。个人而言，我将所有大括号放在单独的行上--当我看到像if() {这样的东西时，会让我发疯，但很难解释别人做这件事是“错误”的。 - Shane

如果新人加入团队，很有可能其中一些人的习惯与团队标准不同。因此，对待编码规范的态度成为你面试实践的一部分。我说这话是因为作为一个对花括号等放置方式有着强烈感觉的人，在不同的团队中不得不进行修改。 - Liz Albin

Answer 1

实际上，我发现在命名方面严格要求比在格式方面严格要求更为重要。

幸运的是，制定一套命名规范要容易得多。

只要某人的代码在可读性方面没有偏离常规太远，我认为没有必要限制他们个人的风格。

- Jon Seigel

---

+1，关于格式的大部分争论都是无意义的，如果你有一个好的编辑器/IDE。不要为个人喜好而争吵，尤其是在有工具可以缓解或消除这个问题的情况下。 - VolkerK

+1 - 标准化只有在有意义的情况下才是必要的。避免为了一致性而强制规定所有事情。@VolkerK - 你的意思是“无关紧要”。 - Scott Smith

@Scott：哎呀，当然是无用的了... - VolkerK

Answer 2

无论你说什么样的标准，你实际上执行的标准才是最重要的。 关于空格或括号放置位置的规则不会损害任何人的创造力。另一方面，得到一个可以将制表符替换为空格（反之亦然）的编辑器可能是值得的。 如果允许所有开发人员通过格式来表达他们的创意，则存在一个问题：他们会花时间重新格式化代码以符合自己的想法，而不是进行重构。 你不希望出现这种情况。 确保代码经过审查，并且审查的一部分是格式。如果你有开发人员因此变得不高兴，那么他们可能没有他们自认为那么出色。

- Liz Albin

---

也许我曾经处理过一些特别糟糕的东西，但有时我不能重构代码直到我也重新格式化了它。我认为标准应该是“不要在你拥有的自由度上变得愚蠢”。 - Shea Daniels

@Shea 是的。 我也有过这样的经历，遇到了格式非常丑陋，以至于我无法理解作者的意思。 - Liz Albin

Answer 3

是的，一个团队（无论是专业团队、开源团队、爱好小组还是其他类型）应该有其编码规则，每个成员都要遵循，否则会变得一团糟；如果不使用源代码控制系统（即使作为单个开发者），也会很有帮助。

当然，有些方面你不必那么严格（例如格式、空格等），你可以通过源代码控制提交中的一个软件来“强制执行”，因此在他们编写代码时，他们可以随心所欲，但一旦到达源代码控制系统，就会被标准化。但其他方面，特别是命名约定，需要非常严格，因为这不容易由程序进行更改。例如，使用具有描述性的名称而不是单个字母：

for (int i = 0; i<int.MaxValue;i++)

vs

for(int count = 0; count<int.MaxValue;count++)

后者比前者更易读和描述性。

无论你的规则是什么形式，确保每个人在实施时都能发表自己的意见，但不要花太多时间讨论。这样，人们可以陈述自己的观点，而不感到被践踏。

- Femaref

---

希望你不要认为你提供的代码是使用描述性变量名的好样例。 - symcbean

实际上，随着时间的推移（当您习惯了它），第一个变量会变得更易读，因为每个人都知道 i 是循环跟踪变量，而 count 则更加通用，经常用于其他可计数的事物。此外，i 更短，因此您的大脑能够在一眼扫过去时（随着时间的推移）快速处理它，而不必阅读它。 - still_dreaming_1

毫无疑问，@INTPnerd，我也不使用后者，可能是命名约定的一个糟糕示例。 - Femaref

Answer 4

首先，既然您提到了匈牙利命名法，这里有一篇必读的文章Joel's Making Wrong Code Look Wrong。 :-) 该文章讨论了在Joel看来使用匈牙利命名法的好与坏。

原则上，我同意一个团队标准是一件好事。但实际上，我的经验是很难达成一致 - 比如，一个人会对括号放在行末变得极端执着，而另一个人会对将它们单独放在一行变得同样执着。此外，如果没有代码审查或其他机制来确保代码符合标准，执行起来也很困难。我建议努力做到最好的方式；例如，在我之前的例子中，两种方法都相当易读，所以也许可以忽略不计，但如果您正在使用变量命名约定，请不要容忍有人试图使用“a”来表示包含客户名称的变量！

- GreenMatt

---

+1 对于让错误的代码看起来像错误链接。 - Scott Smith

Answer 5

我不确定是否有人谈到过这个话题，但在我的经验中，代码规范最重要的方面是团队中的每个人都同意它们。是的，让一群聪明的程序员就像编码规范这样具有争议的事情达成一致真的很难，但我发现如果讨论直到达成可行的共识，将会带来丰厚的回报。

在之前的工作中，我曾与许多技能娴熟的程序员一起使用各种不同的开发平台，针对各种目标进行开发。工作主要以C为基础，难度较高。我们达成了以下共识：

1. 使用制表符而非空格。
2. C++括号风格（单独的行）
3. 始终添加代码块的大括号。
4. 函数命名为Module_VerbObject [Adjective]，例如GraphicsContext_DrawRectangle（）。
5. 以特定顺序包含语句
6. 功能超过10行时添加注释
7. 注释中包含特定关键字（OPTIMISE，DONOTTOUCH等）
8. 不允许在代码或注释中出现亵渎、指责和归咎的言论。

带来的好处包括：

1. 和谐 - 每个人都能阅读其他人的代码。
2. 新员工可以从任何部分开始 - 不仅仅是“好东西”。
3. 我们可以使用版本控制检入挂钩来查找跨多个平台的问题（这是在持续集成之前的日子里）
4. 更好的构建时间（包含语句排序等）
5. 一段很棒的Perl脚本会查找常见错误，例如未检查malloc（）失败等。如果没有一致的编码风格，这是不可能的。

在较新的职位中，我发现强制执行编码规范几乎是不可能的，必须温和地处理。

- JBRWilkinson

Answer 6

根据您使用的编程语言，您可以购买现成的智能重构工具，将源代码输入其中并进行调整，而不会改变实际含义（当然！），以符合任何“编码标准”（即缩进、大括号风格和其他任意规则）。

我最近看过的一个工具售价约为每个35美元，网站授权1000美元。这只是小钱，您可能在卫生纸上花费的金额都比这高。

将运行重构工具作为源代码检查程序的一部分，并且不必担心它。

- John R. Strohm

---

我认为这是错误的建议 - 在工程师不知情的情况下自动格式化他们的工作，最终会导致当需要维护/修复时，他们放弃对工作的所有权。 - JBRWilkinson

如果你让开发人员格式化他们的代码（例如在IDE中按下键盘，使用共享的格式化规则），他们可以看到格式化程序对他们的代码所做的操作，并进行调整以获得他们满意的结果。 - Scott Smith

@Donal - 但是伟大的代码不是由那些感到所有权的开发人员编写的吗？为什么你会希望有些东西不断地提醒开发人员他们对所创建的内容没有所有权。这难道不会鼓励他们成为9-5工作的人，而不是献身于夜以继日的编码工作的英雄吗？ - Scott Smith

@Scott，我不反对。我想表达的是，如果那个专注于熬夜编码的开发者遭遇意外，他们正在处理的事情不会被视为一部伟大的未完成小说——代码必须留在一个同事可以接手的状态。个人项目采用个人风格，企业项目采用企业风格，希望始终以工作的自豪和成就感为荣。 - user8599

@Donal：在经典著作《计算机编程心理学》中，温伯格认为，“放弃”代码正是应该做的事情之一。他称之为“无自我编程”。你想要的是所有（或至少几个）程序员都能够选择任何给定的代码，并运行它。有些人认为这需要“编码标准”。我认为这需要受过教育的程序员，而管理层认为这比任意编码标准更昂贵。 - John R. Strohm

Answer 7

我会坚持宽松的标准。我曾经合作过的所有程序员都没有遇到过适应另一种编码风格的问题，所以试图变得严苛只会让大家感到不愉快。重要的是强制执行一致的命名约定和合理的缩进，因为代码可读性很重要。当然，代码的正确性和可维护性更加重要，因此代码审查是必不可少的，可以涵盖代码质量的所有方面。

- Jacob

Answer 8

就我所知，当你有限的时间和精力来提高团队代码质量时，将其花费在代码审查上会更有效。即使命名得当、间距整齐的糟糕代码仍然是糟糕的代码。如果你有时间做两者，那么两者都做。但如果你必须选择...

- Scott Smith

Answer 9

是的，他们应该遵循标准。否则就会一团糟。

如果你正在组建一个团队 - 你可以创建一个基于你自己的编码风格的文档。
如果这是任何现有的团队，那么最好先通过讨论达成每个人都同意的标准。

- z-boss

Answer 10

我认为应该有标准。我在Visual Studio 2008中选择了一组特定的自动格式选项，并让所有其他开发人员导入这些设置。

在不同风格之间容易遇到的问题之一是臭名昭著的空格与制表符。在VS 2008中，有时会出现混合缩进样式的情况，按下Ctrl-E，D以格式化整个文档可能会导致VS崩溃。

强制执行相似的样式也可以使您喜欢的源代码管理器中的提交更加清洁，因为您不必让开发人员不断地来回更改彼此的格式。

编辑：关于自由度，我对我的开发人员有一些关于命名约定和可读性的指导方针，但除了格式（开放括号所在行等）之外，没有严格的规则。如果其中一个人将私有字段放在底部或顶部，我不介意。如果我添加了一个新的，我会模仿。

你的问题太过笼统，所以你会得到笼统的答案。我建议分别评估每个个体样式的各个方面及其后果。

- Joel B Fant