您认为软件公司应该向开发人员强加一种编码风格吗？

Question

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

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

Answer 1

我觉得团队（而非公司）需要对合理的一贯作风一套指导方针达成一致。它使维护更直接。

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

Answer 2

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

除了今天的IDE和它们的自动生成功能以外，它并没有太大的麻烦。

P.S： 我有这种讨厌的习惯，把我的牙套放在下一行:)。没有人似乎喜欢它

Answer 3

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

作为一个方面说明，这就是为什么我喜欢Python;因为它已经在如何构建应用程序等方面制定了相当多的规则。将它与Perl，Ruby或任何你有极大自由的地方（在这种情况下并不是那么好）进行比较。

Answer 4

我认为程序员应该能够适应其他程序员的风格。如果一个新的程序员不能适应，那通常意味着新的程序员太固执，不能使用公司的风格。如果我们都可以做我们自己的事情，这将是很好的;但是，如果我们都遵循一些韧体指导原则进行编码，它将使调试和维护更加容易。如果标准经过深思熟虑而不是太严格，这才是真实的。

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

Answer 5

是的，但在合理范围内。

所有现代化的IDE都提供了一键式打印代码，所以在我看来，“缩进”点是非常不相关的。

更重要的是要建立最佳实践：例如，尽可能少使用“out”或“ref”参数......在此示例中，您有两个优点：提高可读性并修复大量错误（很多out参数是代码味道，应该可能被重构）。

超出我的意见是，有点“肛门”和不必要的烦人的开发。

---

好一点的哈米什·史密斯：

风格是最好的 的做法完全不同。 “编码 标准”倾向于将两个 放在一起，这真是令人遗憾。如果人们可以将 款式部分降到最低，并且 专注于最佳做法，那么 可能会增加更多价值。

Answer 6

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

1. 克隆一个开发人员几次，并确保他们都通过相同的培训。希望他们都应该能够编写相同的代码库。
2. 为您的现有开发人员提供有关您所需内容的明确说明。缩进的制表符或空格。大括号坐在哪里。如何评论。版本控制提交准则。

您离开未定义的越多，其中一个开发人员在风格上发生冲突的可能性越高。

Answer 7

该公司应该强加一些风格应该遵循。该指南的风格和程度应该由公司的开发者社区共同决定。

我肯定会制定大括号，缩进，命名等指南...... 您为可读性和可维护性编写代码。总是假定别人会读你的代码。 有一些工具可以自动地将代码格式化，并且您可以强制每个人都使用该工具。

如果您对净看看了StyleCop，FxCop的和ReSharper的

Answer 8

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

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

Answer 9

当然，指导方针很好，除非它是匈牙利符号（ha！），否则它可能会提高一致性并使其他人的代码更容易阅读。这些指导方针应该只是指导方针，而不是对程序员强制执行。你可以告诉我在哪里把我的括号或不使用像临时的名字，但你不能做的是逼我周围有数组括号索引值空间（他们试了一次...）

Answer 10

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

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

在外包公司中，如果客户想要强制执行自己的标准，可以为一个为客户工作的团队制定例外规定。在这种情况下，球队采用客户的标准可能是由他们公司所使用的不兼容。

Answer 11

是。

编码标准是保证一定组织内的代码将遵循最惊喜的原则一种常见的方式：在标准的变量命名到缩进花括号使用起始稠度。

编码人员有自己的风格和自己的标准只会产生一个代码库是不一致的，混乱的，和令人沮丧的阅读，尤其是在大型项目。

Answer 12

These是我曾经工作的公司的编码标准。他们明确界定，并同时通过我花了一段时间来习惯他们的说话，这意味着该代码是可读我们所有人，并统一所有的方式。

我认为编码标准是很重要的一个公司内部，如果没有设置，也将是开发商的问题之间的冲突，并与可读性。

使代码统一一直给最终用户提供更好的代码（所以看起来好像它是由一个人编写的 - 从最终用户的角度来看，它应该 - 该人是“公司”，它也有助于与球队内可读性...

Answer 13

一个共同的编码风格促进一致性，很容易让不同的人很容易理解，维护和扩展整个代码库，不仅使自己的作品。它也使得它更容易让新人们学习的代码更快。因此，任何一支球队应该有代码是如何有望被写入。

重要准则包括指引（没有特别的顺序）：

• 空格和缩进
• 标准注释 - 文件，类或方法头
• 命名约定 - 类，接口，变量的命名空间，文件
• 代码注释
• 项目组织 - 文件夹结构，二进制文件
• 标准库 - 要使用哪些模板，仿制药，容器等
• 错误处理荷兰国际集团 - 例外，HRESULTS，错误代码
• 线程和同步

此外，警惕不能或不愿适应球队的风格，无论他们如何明亮的是程序员。如果他们不通过的队规一玩，他们很可能不会被其他队规如玩。

Answer 14

你认为一个软件公司应该强加开发商编码风格？

不在一个顶向下的方式。软件公司的开发人员应该就共同的编码风格达成一致。

如果是的话，您认为指南应该有多深？

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

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

是的，它使代码更具可读性。根据空格与制表符和（如果选择空格）空格字符数保持缩进一致。另外，就长线达成协议（例如76个字符或120个字符）。

Answer 15

我同意一致性是关键。你不能依靠IDE漂亮打印来节省一天的时间，因为你的一些开发人员可能不喜欢使用IDE，并且当你通过成千上万的源代码文件的代码库进行拖拽时，它不可行打印所有文件，然后执行回滚操作，以便您的VCS不会尝试回退所有更改（以不必要的更新阻塞存储库，从而减轻所有人的负担）。

我至少会建议规范如下（按照重要性递减的顺序排列）：

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

Answer 16

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

Answer 17

我的看法：

• 一些基本的规则是好事，因为它可以帮助大家，因为它停止开发与布局代码
的更清晰的方式创新，以阅读和维护的代码
• 太多的规矩是坏
• 个人风格​​可用于确定代码文件的历史记录。可以使用Diff/Blame工具，但提示仍然有用

Answer 18

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

Answer 19

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

Answer 20

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

我工作的店铺没有统一的编码标准，我可以说我们（作为一个团队）受到的影响非常大。当个人没有意愿时（比如在我的一些同事的情况下），团队领导者不得不摆脱桌面上的拳头，并施加某种形式的标准化编码准则。

Answer 21

Ever语言具有社区使用的一般标准。你应该尽可能地遵循这些规则，以便你的代码可以被习惯于该语言的其他人维护，但是不需要独裁。

创建官方标准是错误的，因为公司编码标准通常太僵硬，无法与普通社区一起使用该语言。

如果您遇到团队成员问题，确实在编码风格上存在问题，那么对于团队来说，轻轻提示在代码审查中并不是一个好主意。

Answer 22

编码标准：是。由于此线程已经涵盖的原因。

造型标准：NO。你的可读性，是我令人迷惑的垃圾，反之亦然。良好的评论和代码因子有很大的好处。还有gnu缩进。

Answer 23

我喜欢伊利亚的答案，因为它包含了可读性的重要性，并将持续集成作为强制机制。 Hibri提到了FxCop，我认为它在构建过程中作为确定构建是否通过的标准之一的使用将比仅记录标准更加灵活和有效。

Answer 24

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

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

Answer 25

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

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

然后，出现了一些冲突，有人被置于不必要面对别人编码风格的不舒服的位置 - 这种对抗应该由工具而不是人来完成。简而言之，在我看来，这种强制执行方法是最不可取的，因为它很容易被忽视，并且简单地要求程序员争辩愚蠢的事情。

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

Answer 26

风格指南非常重要，不管它们是用于设计还是开发，因为它们加速了协作工作人员的沟通和表现（甚至单独按顺序收集旧项目）。 不是在公司内部有一个惯例制度，只是要求人们尽可能没有生产力。大多数项目都需要协作，甚至那些不需要我们自然愿望的人也可以参与编程并保持最新状态。我们的学习欲望阻碍了我们的一致性 - 这本身就是一件好事，但可能会让新员工疯狂地尝试学习他们正在学习的系统。

就像任何其他系统的意思是好的而不是邪恶的，指南的真正力量在于其人民的手中。开发者自己将决定什么是必要的和有用的部分，然后，希望使用它们。

就像法律。或英语。

风格指南应该尽可能深入 - 如果它出现在头脑风暴会议中，应该包括它。你如何评论这个问题很奇怪，因为在这一天结束时，没有办法“强加”风格指南，因为它只是一个指南。

RTFM，然后收集好的东西，并继续与它。

Answer 27

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

我听到人们用来解释为什么样式指导是必要的最常见的原因是用通用样式编写的代码更易于维护以单独样式编写的代码。我不同意。一个专业的程序员是不会当他们看到这越陷越深：

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

...当他们看惯了这一点：

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

而且，我发现它实际上是更容易如果你能通过简单地识别他们的风格来识别编写原始代码的程序员，在某些情况下维护代码。去问问他们为什么在10分钟内以这样一种令人费解的方式实施了这个小发明，而不是花一天的好时间去弄清楚他们为什么会做出意想不到的技术原因。诚然，程序员应该评论代码来解释他们的推理，但在现实世界中，程序员通常不会。

最后，如果需要乔10分钟退格&移动他的大括号，以便比尔可以花费3秒钟的时间查看代码，是否真的可以节省时间让比尔做一些不自然的事情？

Answer 28

约定有两种类型。

A类约定：“请做这些，最好是”

和B类：“请在路的右手边开车”，而它是好的带动另一侧，如只要每个人都以同样的方式行事。

有没有这样的事情作为一个单独的团队。某个好公司的所有代码都以某种方式连接起来，风格应该一致。 让自己习惯于一种新风格比二十种不同风格更容易。

此外，新开发者应该能够尊重现有代码库的做法并遵循它们。