我的团队是否应该使用一些公认的通用编码标准作为自己的基础？

我所在的研发团队已决定采用编码标准。我们只是最近才成立的，我们自己的代码和通用编码时间太少，无法将我们的标准/惯例文档建立在我们团队有机发展的基础上，也无法借鉴我们自己的代码中的良好示例等。

现在，我们每个人都有一些过去工作场所的经验-尽管我们每个人都没有处于这样一种状态：“让我们在这里采用这份全面的文件，我发现它适合我们在这里从事的工作”（*）。另外，我们中的某些人（包括我本人）只有没有官方编码标准的地方的经验，或者在不同的环境中用不同的语言编写（高压每周发布的生产环境，而不是更加注重研究的开发工作）

因此，我一直在考虑的一种选择是获取一个相对知名且备受关注的文档，剪掉我们不在乎/关心的内容，并根据我们的偏好进行一些修改。

这是常见的做法吗？您认为这是个好主意吗？如果是这样，那将是一个合理的“基准”编码标准（不要告诉我哪个是最好的，我不想在这里引发宗教冲突；只需指出可以在其基础上进行全面或“中立”的内容） ）

笔记：

• 我们希望可以使用C，C ++，OpenCL，CUDA，Python。
• 我们是一个由4人+经理组成的团队，预计在一年左右的时间内增长到大约5-6。
• 在我们公司中，团队几乎完全是自治的，通常根本不互动（甚至不使用彼此的代码-工作是在完全不同的项目上）；所以-没有公司范围内的考虑。
• 关于工具，目前我们知道我们将使用Eclipse，因此它的代码格式化程序至少将成为一种工具。Ctrl + Shift + F很久以来就是我的朋友
• 在编写Java时，我采用了尽可能严格遵循Bloch的Effective Java的做法。现在，这还不是一个编码标准，但是您可以将一些砖，水泥和砂浆称为编码标准。我当时正在考虑将类似的内容作为“混合”的一部分（注意我们不使用Java）。
• 我指的是更广泛意义上的编码标准，例如采用对P.SE问题的回答中提出的建议。
• 我找到了大量的C ++编码标准文档 ; 也许我应该挖掘我们的基线。
• （*）并非完全正确，但我不想使这个问题复杂化。

换句话说，您在问是否应该借用您发现的外部标准来启动团队的编码标准。听起来团队中没有人对这些标准应该有什么强烈的意见。

毫无疑问，答案是肯定的。

外部标准胜过一切。查看“ https://softwareengineering.stackexchange.com/q/84203/53019 ”中的答案，以了解拥有标准的一些优势。从您的角度来看，一致性和更改基础至关重要。

还可以参考“ 在工作中处理编码标准（我不是老板） ”，因为它涉及团队在选择标准时应考虑的一些团队动态。团队需要拥有自己的编码标准，因此每个人都愿意遵守对每个人编码方式的限制。

您已链接到此问题，但值得指出最重要的答案，并且它应该着重于理解为什么要达到要求。如果使用外部标准，您的团队将很难理解所有这些要求的基础。但是，如果您仅仅因为您的团队需要一些东西而接受它们，那么就很容易继续将外部标准更改为对您的团队更有效的东西。

制定任何标准都可以使您填充将与IDE一起使用的格式设置规则（在您的情况下为Eclipse）。“ 强制代码重新格式化的优点和缺点 ”对团队中的每个人都具有好处，即与他们正在处理的代码保持一致，并使您能够重新格式化可从其他项目中借用的代码片段。使用外部标准的另一个好处是，它可能已经预先填充在IDE的代码格式化部分中。

团队中的某人可能会抱怨该标准的特定部分，并将其归咎于您使用外部标准作为基础。他们是否已阅读以下内容：
- 我讨厌我们的一种编码标准，这使我发疯，如何处理它？
- 在处理遗留代码时如何克服自己的编码偏见？
然后意识到他们可能会抱怨标准中的某些内容，无论它来自何处。在我工作过的团队中，我尚未看到一个大家都喜欢的标准，b）每个人都同意该标准的每个部分。返回一些早期链接，以了解如何处理这些问题。

附录中，您询问应使用“哪个”。我特别不愿回答这个问题，因为任何答案都可能与引发火焰战争的观点争论不休。但是，您可以查看IDE（Eclipse）并查看它作为标准配置提供了哪些选项。我还要进行一些搜索，看看是否有任何项目可以插入您的IDE并提供其他标准选项供您选择。对与错，这些标准已经为您填充，可以为您的团队节省为每个人配置它的大量工作。

我将从python开始。Python具有编码准则，几乎每个Python程序员都遵循该准则。它们是称为PEP8的官方文档的一部分。

由于历史原因，C / C ++实在是一团糟，但是由于python并非如此，因此为了保持一致性，我建议您也遵循C / C ++中的python命名约定。

现在，对于C ++来说，就共同的习惯用法达成一致并确保每个人都能理解合理的现代C ++样式比对命名约定的任何争执实际上更为重要。您应该从C ++编码标准开始，并从在线资源中确保阅读C ++ FAQ。

您甚至不能在不区分编码标准和编码样式标准的情况下讨论此主题。

编码标准是一组规则，这些规则定义了允许使用的语言机制，不允许的语言机制以及使用方式。换句话说，如果编码标准解决了某些非标准扩展名，则可以定义所用语言的子集和/或超集。

编码样式标准仅涉及外观问题：在何处放置花括号和空格，如何命名标识符，如何放置注释等。

这两个不同的内容可能位于同一文档中。但是，最严格的编码标准与样式无关，我在下面建议的标准与样式无关。最可能的原因是编码风格非常主观，因此在意见冲突时会引起很多摩擦。

对于C / C ++，具有最佳声誉的编码标准是MISRA的那些。它们主要用于安全/关键任务应用程序，但是由于使程序更安全的关键是消除并避免错误，因此MISRA标准适用于不需要错误的任何编程分支。

CERT的标准也相当知名，并且偏重于桌面编程和软件安全性（而非安全性）。CERT具有C，C ++，Java和Perl的标准，并且这些标准是免费的。

我将从查看MISRA和CERT开始，而不是从网上找到一些随机车库标准。

使用现有标准作为自己的基础具有多个优点。您的代码可能与外部代码更相似，从而使读取/集成代码更加容易。此外，如果您选择了一个好的标准，那么它将由已经有充分理由决定其特定规则的专家进行了审查。只要您的团队中没有人特别依赖某个标准，就没有理由不使用现有标准作为自己的基础。

如果不确定使用哪种编码标准，则有一些显而易见的理想首选。按以下顺序排列：
1.您的IDE已支持任何标准。这可能是可配置的。
2.编译器作者使用/推荐的任何标准。
3.主框架的作者使用/推荐的任何标准（如果存在）。
4.您的编程语言的作者/设计者所使用/推荐的标准。
5.大型公司使用/推荐的标准。

我建议具有技术专长的人员阅读您所使用的任何标准，以此作为自己标准的基础。一个好的标准通常会为每条规则辩护，这将帮助您修改标准以最适合您的需求。

标准通常有助于通信和维护。我认为，它应该服从某些条件，尤其是在小型团队中，并且应该不断发展。给他们打电话的准则可能会有所帮助:-)

查看Google指南以获取灵感。

不，我不会打扰-我认为唯一的好处是，如果您的团队也转移到使用这些标准的地方，那不是您想要发生的事情:)

标准只是为了鼓励更轻松的协作而存在，因此，如果您知道#define宏始终是大写的，那么当您在代码中看到大写的标识符时，便会清楚地知道其为宏。同样，其他命名约定或样式约定也会提醒您正在处理的内容。

我发现诸如文件位置和名称之类的标准比代码更有用（毕竟，代码具有各种形状和大小，并且您仍然必须阅读它），但不知道readme.txt位于/ bin / doc / debug中/ release / documents是一个真正的痛苦（这是一条曲折的道路，但这是另一个故事）。

我建议您在进行时建立自己的标准。这样，您不仅得到了所有人都喜欢的人，而且得到了绝对适合您，您的团队和所做工作的人。如果您决定不真正在意while循环是什么样子，或者必须以某种方式缩进case语句，那么您就很好了。如果您决定禁止++运算符，那也很好。您自己选择。

您必须使查找和更新它变得容易，也许是Wiki还是从文本描述中自动生成的网页，但是否则-继续吧。有些人对狂热地遵循标准而不是编写好的代码更感兴趣，因此他们对标准抱有幻想的态度，他们不喜欢这样-制定自己的标准以在需要的地方提供帮助。