您是否认为软件公司应该将开发人员强加给编码风格？

Question

如果您认为不应该，请解释原因。

如果是，您认为指南有多深？例如，应该包含代码缩进？

Answer 1

我认为团队（而不是公司）需要就合理一致的风格达成一套指导方针。它使维护更加简单。

有多深？你可以同意的浅薄。它越短越清晰，所有团队成员都越有可能同意并遵守它。

Answer 2

您希望每个人都以标准方式阅读和编写代码。有两种方法可以实现这一目标：

1. 多次克隆一位开发人员并确保他们都接受相同的培训。希望他们都应该能够编写相同的代码库。
2. 为您现有的开发人员提供您所需要的明确指示。用于缩进的制表符或空格。坐在哪里。如何评论。版本控制提交指南。

你离开未定义的越多，其中一个开发者在风格上发生冲突的概率就越高。

Answer 3

公司应该强调应该遵循一些风格。什么样的风格和指南的深度应该由公司的开发者社区共同决定。

我绝对会在括号，缩进，命名等方面制定指导方针...... 您编写代码以实现可读性和可维护性。总是假设其他人要读你的代码。 有些工具可以自动神奇地格式化您的代码，您可以强制要求每个人都使用该工具。

如果你在.Net上看看stylecop，fxcop和Resharper

Answer 4

  

您认为软件公司应该给开发人员带来编码风格吗？

不是自上而下的方式。软件公司的开发人员应该就共同的编码风格达成一致。

  

如果是，您认为指南有多深？

他们应该只描述与众所周知的惯例的差异，试图保持偏差最小化。这对于像Python或Java这样的语言来说很容易，对于C / C ++来说有点模糊，而对于Perl和Ruby来说几乎是不可能的。

  

例如，应该包含代码缩进吗？

是的，它使代码更具可读性。保持缩进在空格与制表符和（如果选择空格）空格字符数方面一致。此外，同意长线的保证金（例如76个字符或120个字符）。

Answer 5

是的，但在合理范围内。

所有现代IDE都提供了一键式代码，因此在我看来，“缩进”这一点非常无关紧要。

更重要的是建立最佳实践：例如，尽可能少地使用“out”或“ref”参数......在这个例子中，你有两个优点：提高可读性并修复很多错误（许多输出参数是代码气味，应该重构）。

在我的诚实意见中，超越这一点，对于开发者而言，有点“肛门”并且不必要地烦恼。

---

Hamish Smith的好点：

  

风格与最佳风格截然不同   实践。 “编码”真是太遗憾了   标准'倾向于推动两者   一起。如果人们可以保持   风格部分到最低限度   专注于最佳实践   可能会增加更多的价值。

Answer 6

我不相信开发团队应该遵循他们必须遵循的风格指南作为一般规则。有例外，例如the use of <> vs. "" in #include statements，但这些例外情况应该来自必要。

我听到人们用来解释为什么样式指南是必要的最常见的原因是用通用样式编写的代码更容易维护用各种样式编写的代码。我不同意。专业程序员在看到这个时不会陷入困境：

for( int n = 0; n < 42; ++42 ) {
 // blah
}

......当他们习惯看到这个时：

for(int n = 0; n < 42; ++42 )
{
 // blah
}

此外，我发现在某些情况下维护代码实际上更容易，如果你能通过简单地识别他们的风格来识别编写原始代码的程序员。去问他们为什么他们在10分钟内以如此复杂的方式实施Gizmo，而不是花费一天的大部分时间来弄清楚他们为什么会做出意想不到的事情的技术原因。确实，程序员应该对代码进行评论来解释他们的推理，但在现实世界中，程序员通常不这样做。

最后，如果需要Joe 10分钟的退步＆amp;移动他的花括号，这样Bill可以花费3秒钟来查看代码，是否真的可以节省任何时间让比尔做一些对他来说不自然的事情？

Answer 7

我相信拥有一致的代码库非常重要。它增加了ur代码的可维护性。如果每个人都期望相同类型的代码，他们可以轻松阅读和理解它。

此外，考虑到今天的IDE及其自动构建功能，这并不是一件容易的事。

P.S：  我有这个烦人的习惯，把我的大括号放在下一行:)。似乎没有其他人喜欢它

Answer 8

最好的解决方案是让IDE将这种格式视为元数据。例如，操作员周围的开口大括号位置（当前行或下一行），缩进和空白区域应该是可配置的，而无需更改源文件。

Answer 9

我认为程序员应该能够适应其他程序员的风格。如果新程序员无法适应，那通常意味着新程序员太顽固，无法使用公司的风格。如果我们都能做自己的事情，那就太好了;但是，如果我们都按照一些麻烦指南进行编码，它会使调试和维护变得更容易。只有在经过深思熟虑并且没有太多限制的情况下才能实现这一点。

While I don't agree with everything, this book contains an excellent starting point for standards

Answer 10

在我看来，我认为标准和风格指南非常必要。因为当你的代码库增长时，你会希望它保持一致。

作为旁注，这就是我喜欢Python的原因;因为它已经对如何构建应用程序等施加了很多规则。与Perl，Ruby或任何你有极端自由的地方相比（在这种情况下这不是那么好）。

Answer 11

与其他人提到的一样，我认为需要通过工程或团队 - 公司（即业务部门）不应参与此类决策。

但我要补充的另一件事是，任何实施的规则都应该由工具强制执行，不是。最糟糕的情况，IMO，是一些过度狂热的语法势利（是的，我们存在;我知道，因为我们可以闻到我们自己的味道）写了一些文档，概述了一组编码指南，绝对没有人真正阅读或遵循。它们随着时间的推移而变得过时，随着新人加入团队并且老人们离开，他们只会变得陈旧。

然后，出现了一些冲突，并且有人因为不得不与其他人讨论编码风格而感到不舒服 - 这种对抗应该通过工具而不是人来完成。简而言之，在我看来，这种强制执行方式是最不可取的，因为它太容易被忽视，只是让程序员争论愚蠢的事情。

更好的选择（再次，IMO）是在编译时（或类似的东西）抛出警告，只要你的构建环境支持这个。在VS.NET中配置它并不难，但我不知道其他具有类似功能的开发环境。

Answer 12

风格指南非常重要，无论是用于设计还是开发，因为它们可以加速协作工作的人员的沟通和表现（甚至是单独的，顺序的，就像拾取旧项目的部分一样）。 不在公司内部拥有一个公约系统只是要求人们尽可能没有生产力。大多数项目都需要协作，即使是那些不合作的项目也可能容易受到我们运用编程排序并保持最新状态的自然愿望的影响。我们的学习欲望妨碍了我们的一致性 - 这本身就是一件好事，但是可以让一个新员工疯狂地试图学习他们正在跳入的系统。

与任何其他善意而非邪恶的制度一样，指南的真正力量在于其人民的手中。开发人员自己将确定必要和有用的部分是什么，然后希望使用它们。

像法律一样。或者英语。

风格指南应该像他们想要的那样深 - 如果它出现在头脑风暴会议中，它应该被包括在内。你如何措辞这个问题很奇怪，因为在一天结束时，没有办法“强加”一个风格指南，因为它只是一个指南。

RTFM，然后收集好东西并继续使用它。

Answer 13

标准有很多充分的理由来定义应用程序的开发方式和代码的外​​观。例如，当每个人都使用相同的标准时，自动样式检查器可以用作项目CI的一部分。 使用相同的标准可以提高代码的可读性，并有助于减少团队成员之间关于以不同方式重新分解相同代码的紧张关系。 因此：

• 特定团队开发的所有代码都应遵循相同的标准。
• 为特定项目开发的所有代码都应遵循相同的标准。
• 属于同一公司的团队最好使用相同的标准。

在外包公司中，如果客户希望强制执行自己的标准，则可以为为客户工作的团队制定例外。在这种情况下，团队采用客户的标准，这可能与他们公司使用的标准不相容。

Answer 14

我完全同意应该应用编码标准，并且它应该几乎总是在团队层面。但是有一些例外。

如果团队正在编写将由其他团队使用的代码（这里我的意思是其他团队将不得不查看源代码，而不仅仅是将其用作库），那么制定通用标准会带来好处所有团队都在使用它。同样，如果公司的政策是经常将程序员从一个团队转移到另一个团队，或者处于一个团队经常想要重用另一个团队的代码的位置，那么最好在整个公司内部施加标准。

Answer 15

我喜欢Ilya的答案，因为它结合了可读性的重要性，以及使用持续集成作为执行机制。 Hibri提到了FxCop，我认为它在构建过程中的使用是确定构建是否通过的标准之一，它比仅仅记录标准更灵活和有效。

Answer 16

有两种类型的约定。

A类约定：“请做这些，它更好”

和B型：“请在道路的右侧行驶”，只要每个人都以同样的方式行驶，可以在另一侧开车。

没有一个单独的团队。良好公司中的所有代码都以某种方式连接，风格应该是一致的。 让自己习惯一种新风格比使用二十种不同风格更容易。

此外，新开发人员应该能够尊重现有代码库的实践并遵循它们。

Answer 17

编码标准：是的。由于此主题中已涵盖的原因。

造型标准：没有。你的可读性，是我令人生畏的垃圾，反之亦然。良好的评论和代码保理具有更大的好处。还有gnu缩进。

Answer 18

Ever language具有社区使用的一般标准。您应该尽可能地遵循这些，以便您的代码可以由习惯于该语言的其他人维护，但是没有必要对其进行独裁。

创建官方标准是错误的，因为公司编码标准通常过于严格，无法与使用该语言的一般社区一起流动。

如果你遇到团队成员的问题，那么在编码风格方面确实存在问题，对于小组来说，这是一个很好的建议，在代码审查中不是一个好主意。

Answer 19

每家公司都应该。一致的编码风格确保整个团队的代码库具有更高的可读性和可维护性。

我工作的商店没有统一的编码标准，我可以说我们（作为一个团队）非常受此影响。当个人没有遗嘱时（比如我的一些同事），团队负责人必须将拳头放在桌面上并施加某种形式的标准化编码指南。

Answer 20

是的，使用通用命名标准以及文件后面的类和代码的通用布局。其他一切都是开放的。

Answer 21

现代IDE允许您定义格式模板。如果存在公司标准，则开发一个配置文件，该文件定义您关注的所有格式值，并确保每个人在签入代码之前运行格式化程序。如果你想对它更加严格，可以为你的版本控制系统添加一个提交钩子，在代码被接受之前缩进代码。

Answer 22

我的意见：

• 一些基本规则很好，因为它可以帮助每个人阅读和维护代码
• 太多的规则都是不好的，因为它会阻止开发人员以更清晰的方式布局代码进行创新
• 单个样式可用于确定代码文件的历史记录。可以使用Diff / blame工具，但提示仍然有用

Answer 23

我同意一致性是关键。你不能依靠IDE漂亮的打印来节省时间，因为你的一些开发人员可能不喜欢使用IDE，而且当你在搜索成千上万个源文件的代码库时，它根本不可行。当你开始处理它们时打印所有文件，然后执行回滚，这样你的VCS就不会尝试提交所有的更改（用不必要的更新来堵塞存储库）。

我建议至少标准化以下（按重要性递减顺序）：

• 空白（如果您选择的风格符合某些共享工具的自动漂亮打印，则最简单）
• 命名（文件和文件夹，类，函数，变量......）
• 评论（使用允许自动生成文档的格式）

Answer 24

一种常见的编码风格提高了一致性，使不同的人可以轻松地理解，维护和扩展整个代码库，而不仅仅是他们自己的部分。它还使新人更容易更快地学习代码。因此，任何团队都应该有关于如何编写代码的指导原则。

重要指南包括（无特定顺序）：

• 空格和缩进
• 标准注释 - 文件，类或方法标题
• 命名约定 - 类，接口，变量，命名空间，文件
• 代码注释
• 项目组织 - 文件夹结构，二进制文件
• 标准库 - 使用哪些模板，泛型，容器等
• 错误处理 - 异常，hresults，错误代码
• 线程和同步

另外，要警惕那些不能或不会适应团队风格的程序员，无论他们多么聪明。如果他们不参加球队规则之一，他们可能也不会参加其他球队规则。

Answer 25

These是我曾经工作过的公司的编码标准。它们定义得很好，虽然我花了一段时间才习惯它们，但这意味着我们所有人都可以读取代码，并且一直都是统一的。

我认为编码标准在公司内部很重要，如果没有设置，开发人员之间会发生冲突，可读性问题也会发生。

让代码一直统一为最终用户提供更好的代码（因此它看起来好像是由一个人编写的 - 从最终用户的角度来看，应该是 - 该人是“公司” “这也有助于团队内部的可读性......

Answer 26

是

编码标准是确保某个组织内的代码遵循最低惊喜原则的常用方法：从变量命名到缩进到大括号使用的标准一致性。

具有自己的样式和自己的标准的编码器只会产生一个不一致，令人困惑和令人沮丧的代码库，特别是在大型项目中。

Answer 27

当然，指南是好的，除非它是使用不当的匈牙利表示法（哈！），它可能会提高一致性并使阅读其他人的代码更容易。这些指南应该只是指导原则，而不是对程序员强制执行的严格规则。你可以告诉我在哪里放我的大括号或不使用像temp这样的名字，但你不能做的就是强迫我在数组括号中的索引值周围有空格（他们试过一次......）

Answer 28

是的，我认为公司应该。开发人员可能需要习惯编码风格，但在我看来，优秀的程序员应该能够使用任何编码风格。正如Midhat所说：拥有一致的代码库非常重要。

我认为这对于开源项目也很重要，没有主管可以告诉您如何编写代码，但是许多语言都有关于代码命名和组织方式的规范。将开源组件集成到项目中时，这有很大帮助。