我是否希望编程团队遵循严格的编码标准？

Question

在与一组开发人员合作时，我个人非常喜欢遵循内部编码标准。我觉得它为代码带来了连续性，让人们可以更轻松地扩展代码库，关闭工作，并在困难的任务中互相帮助。 另一方面，我知道有很多人相信只要编码按时完成并且它起作用我们应该接受个别编码器风格的差异。

看到硬币的两面，我发现很难确定是否有点扼杀程序员风格是否值得通过拥有一个相当标准的代码库获得的（有时是边缘的，有时是大的）好处。特别是在速度很重要的敏捷开发框架内工作时，我认为这是一个更重要的问题。

为了加剧这种情况，我是一名PHP程序员，所以你很少会遇到两个同样风格的程序员，因为它主要是一门自学成才。

最好是将一套松散的标准作为建议，只强制要求非常重要的项目（比如用变量名来限制匈牙利表示法）或者最好是铁拳，并且要求缩进是制表符而不是空格和括号永远都是自己的。

编辑：

本来应该在问题中看到我的错误 - 我想我对标准应该有多严格感兴趣 - 如果他们有很大的自由度，或者我应该把它锁紧吗？

Answer 1

在实践中，我发现在命名时严格要比严格格式化更为重要。

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

只要有人的代码在可读性方面没有出路，我就不明白为什么有必要限制自己的个人风格。

Answer 2

无论您的标准是什么，您的实际标准都是您执行的标准。

没有人的创造力受到关于有多少空间和大括号去的规则的伤害。另一方面，获得一个用空格替换制表符的编辑器可能是值得的（反之亦然）。

允许所有开发人员通过格式化表达他们的创造力的一个问题是，他们将做的是：花时间重新格式化东西以匹配他们的想法，而不是重构。

你不希望这样。

确保审核代码并且审核的部分内容是格式。如果你的开发人员因此而变形，那么他们可能并不像他们想象的那么壮观。

Answer 3

PHP有一个标准吗？

（Cue downvotes a-plenty）

Answer 4

是的，一个团队（让它成为一个专业或开源团队或爱好团体，或其他团队）应该有每个成员都遵循的编码规则，否则将是一个大混乱;如果您不使用源代码控制系统（即使作为单个开发人员，它仍然有用），甚至更多。

编辑以反映OP编辑

某些区域你不必非常严格（例如格式化，空格，你可以通过源代码控制提交中的一个软件“强制执行”，所以当它们编码时，它们可以做到比如，但是当它到达源代码控制时，它会被标准化），但是其他领域，特别是命名约定需要非常严格，因为这不容易被程序改变。例如，使用描述性名称而不是单个字母

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

VS

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

后者比第一种更具可读性和描述性。

无论你的约定是什么形式或形式，都要确保每个人在实施时都能给出自己的意见，但不要花太多时间讨论它。这样，人们可以陈述自己的意见，不要觉得自己被踩了。

Answer 5

首先，既然你提出了匈牙利符号，这里是Joel's Making Wrong Code Look Wrong文章的强制性链接。 :-)它讨论了如何使用匈牙利人的Joel认为好的和坏的方式。

原则上，我同意团体标准是一件好事。在实践中，我的经验是他们很难同意 - 例如一个人会对开放式的parens在线路末端有所了解，而另一个人则将他们自己排成一线并同样具有宗教信仰。它们也难以执行，特别是如果没有代码审查或其他机制来确保代码符合标准。我会说努力做到最好;例如在我之前的例子中，任何一种方法似乎都是相当可读的，所以也许让它滑动，但是如果你使用变量命名约定，当有人试图使用'a'作为包含客户名称的变量时，不要让它滑动！ / p>

Answer 6

我不确定是否有人覆盖了这一点，但根据我的经验，编码标准最重要的方面是团队中的每个人都同意。是的，真的很难让一群聪明的程序员同意像编码标准这样有争议的事情，但我发现在讨论它之前需要付出红利才能达成协议。

在之前的一个角色中，我有各种熟练的程序员使用许多不同的平台来开发各种目标。这项工作主要是基于C的，而且很复杂。我们同意了这样的话：

1. 标签而不是空格。
2. C ++支撑样式（单独的行）
3. 始终为代码块添加大括号。
4. 函数命名是Module_VerbObject [形容词]，例如， GraphicsContext_DrawRectangle（）
5. 按特定顺序包含语句
6. 注释功能超过10行
7. 评论中的特定关键字（OPTIMIZE，DONOTTOUCH等）
8. 代码或评论中没有咒骂，命名/羞辱/指责

好处是：

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

在较新的角色中，我发现几乎不可能“强制执行”编码标准，必须轻轻地完成。

Answer 7

根据您使用的语言，您可以购买现成的智能重新格式化器，它将获取源代码并按摩它，而不会改变实际含义（DUH！），几乎任何“编码标准”（阅读：关于缩进，大括号样式和诸如此类的任意规则。

我前几天看了一个价格约为35美元1美元的费用，1000美元的网站许可费用。这是鸡饲料。你可能在卫生纸上花的钱多了。

运行重新格式化程序部分的源代码检查过程，不要担心。

Answer 8

我会坚持松散的标准。没有与我合作的程序员在适应另一个人使用的编码风格时遇到了问题，所以不要试图通过欺骗来激怒每个人。强制执行的重要事项是一致的命名约定和理智的缩进，因为代码可读性很重要。当然，代码的正确性和可维护性更为重要，因此代码审查可以涵盖代码质量的所有方面，这是必不可少的。

Answer 9

对于它的价值，我发现当你有足够的时间和精力专注于团队的代码质量时，它可以更有效地用于代码审查。正确命名，整齐排列的差代码仍然是糟糕的代码。如果你有时间两者兼顾，那么两者都要做。但如果你不得不选择......

Answer 10

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

如果您创建团队 - 您可以根据 编码样式创建文档 如果它是任何现有的团队，那么你最好先通过讨论来达成每个人都同意的标准。

Answer 11

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

在不同风格中你很容易遇到的问题是臭名昭着的空间与标签。在VS 2008中，有时会出现混合缩进样式并且命中Ctrl-E, D格式化整个文档会导致VS崩溃的情况。

强制执行样式相似性也会使您喜爱的源代码管理器中的提交更加清晰，因为您没有让开发人员不断地来回更改彼此的格式。

编辑关于纬度，我对开发人员有一些关于命名约定和可读性的指导，但是除格式化之外没有严格的规则（开头括号的行等等）。我不介意其中一个人把私人领域放在底部或顶部。如果我添加一个新的，我会模仿。

你的问题只是模糊和笼统，所以你会得到一般答案。我说分别判断个人风格的各个方面及其后果。

Answer 12

编码标准或任何其他类型的过程不能替代技能。如果你的团队熟练并且正在完成工作（并且完成了我也意味着他们生产的东西是可维护的），那么编码标准并不能真正让你在任何地方。

Answer 13

如果读取的格式与您习惯的格式不同，则可以使用eclipse中的代码格式化选项。

Answer 14

Jon（上图）绝对正确，命名是标准化的重要事项。但是对于任何给定的产品，代码库都需要有相当程度的标准化。支持团队中的新开发人员。

如果您没有真正快速构建，并且有适用于您的语言的“自动格式化程序”，则可以创建元代码作为构建的一部分。

您可以保留两个不同的树，一个仅供参考，一个实际工作。开发人员以他们想要的任何样式编写（只要他们以标准方式命名），并且他们的代码通过“标准化程序”推送到编译器使用的另一个树中。这允许个人维护他们自己的样式和项目的陌生人，如果他们接管了外国风格的代码，就可以从“参考版本”开始。

我发现在代码审查中有用的另一个工具是.net的反射器，它允许我选择语言来查看反编译的程序集。我通常不会对私有变量名称感兴趣，这确保了我只有审查“可编辑的代码”