如果我们认为不应该，请说明原因。

如果是，我们认为准则应有多深？例如，应该包括代码缩进吗？

解决方案

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

此外，考虑到当今的IDE及其自动格式化功能，这也没有什么麻烦。

附言：
我有把这个括号放在下一行的烦人的习惯：)。似乎没有人喜欢它

我认为，使用标准和样式指南非常必要。因为随着代码库的增长，我们将希望使其保持一致。

附带说明，这就是为什么我喜欢Python。因为它已经在如何构造应用程序等方面强加了很多规则。将其与Perl，Ruby或者任何我们拥有极大自由的地方(在这种情况下，这不是很好)进行比较。

我认为程序员应该能够适应其他程序员的风格。如果新程序员无法适应，通常意味着新程序员过于固执，无法使用公司风格。如果我们都能做自己的事，那将是很好。但是，如果我们都按照一些野蛮的准则进行编码，那么它将使调试和维护更加容易。只有在对标准进行了深思熟虑且不太严格的情况下，这才是正确的。

尽管我不同意所有这些，但本书包含了一个很好的标准起点

是的，但在合理范围内。

所有现代IDE都提供一键式代码漂亮的外观，因此，在我看来，"缩进"点是无关紧要的。

更重要的是建立最佳实践：例如，尽可能少地使用" out"或者" ref"参数...在此示例中，我们有2个优点：提高了可读性并修复了很多错误(很多错误)。 out参数是一种代码异味，可能应该重构)。

以我的诚实观点，超越这一点会给开发人员带来一些"肛门"和不必要的烦恼。

哈米什·史密斯(Hamish Smith)的观点是：

Style is quite different from best
  practices. It's a shame that 'coding
  standards' tend to roll the two
  together. If people could keep the
  style part to a minimum and
  concentrate on best practices that
  would probably add more value.

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

• 克隆一个开发人员几次，并确保他们都经过相同的培训。希望他们都应该能够编写相同的代码库。
• 向现有开发人员明确说明要求。缩进的制表符或者空格。大括号坐在哪里。如何发表评论。版本控制提交准则。

我们留下的不确定性越多，开发人员之一就风格发生冲突的可能性就越高。

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

有多深？我们可以同意的尽可能浅。越短越清晰，所有团队成员都同意并会遵守的可能性就越大。

公司应强加某种风格。公司的开发者社区应共同决定哪种风格以及指导的深度。

我肯定会就大括号，缩进，命名等制定指导原则...
我们编写代码以提高可读性和可维护性。始终假设其他人将要阅读代码。
有一些工具可以自动神奇地格式化代码，并且我们可以要求每个人都可以使用该工具。

如果我们使用的是.Net，请查看stylecop，fxcop和Resharper

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

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

当然，准则是好的，并且除非它使用不当是匈牙利符号(ha！)，否则它可能会提高一致性，并使阅读其他人的代码更加容易。指导原则应该只是指导原则，而不是对程序员强制执行的严格规则。我们可以告诉我在哪里放括号或者不使用诸如temp之类的名称，但是我们不能做的是强迫我在数组括号中的索引值周围留空格(他们尝试过一次...)

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

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

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

是的。

编码标准是确保特定组织内的代码遵循"最不惊奇的原则"的一种常用方法：从变量命名到缩进再到大括号的使用，标准的一致性。

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

这些是我曾经工作过的公司的编码标准。它们的定义很明确，虽然花了我一段时间才能习惯它们，但这意味着代码对我们所有人都是可读的，并且贯穿始终。

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

始终保持统一的代码为最终用户提供了更好的代码(因此，看起来好像是由一个人编写的，从最终用户的角度来看，该人应该是"公司"，这也有助于在团队中具有可读性...

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

重要准则包括(无特定顺序)：

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

另外，要警惕那些不能适应团队风格的程序员，无论他们多么聪明。如果他们不遵守某个团队规则，那么他们也可能不会遵守其他团队规则。

Do you think a software company should impose developers a coding-style?

并非以自上而下的方式。软件公司的开发人员应就通用的编码风格达成共识。

If yes, how deep should the guidelines be in your opinion?

他们只应描述与众所周知的约定的差异，以尽量减少偏差。对于像Python或者Java这样的语言来说这很容易，对于C / C ++来说这有点模糊，而对于Perl和Ruby来说几乎是不可能的。

For example, indentation of code should be included?

是的，它使代码更具可读性。就空格与制表符以及(如果选择空格)空格字符数而言，缩进要保持一致。另外，请约定长行的边距(例如76个字符或者120个字符)。

我同意一致性是关键。我们不能依靠IDE漂亮的打印来节省一天的时间，因为某些开发人员可能不喜欢使用IDE，并且因为当我们浏览成千上万个源文件的代码库时，在开始处理所有文件时，请先打印所有文件，然后再执行回滚操作，以使VCS不会尝试回退所有更改(使用不必要的更新阻塞存储库，这会给每个人造成负担)。

我建议至少对以下各项进行标准化(按重要性从高到低的顺序)：

• 空格(如果选择与某些共享工具的自动漂亮打印相符的样式，这是最简单的方法)
• 命名(文件和文件夹，类，函数，变量等)
• 注释(使用允许自动生成文档的格式)

最好的解决方案是让IDE将这种格式视为元数据。例如，在不更改源文件的情况下，应该可配置运算符开头的花括号位置(当前行或者下一行)，缩进和空格。

我的想法：

• 一些基本规则很不错，因为它可以帮助所有人阅读和维护代码
• 太多的规则是不好的，因为它使开发人员无法通过更清晰的代码布局方式进行创新
• 个别样式对于确定代码文件的历史记录可能很有用。可以使用差异/非理性工具，但提示仍然有用

现代IDE可让我们定义格式模板。如果存在公司标准，则开发一个配置文件，该文件定义我们关心的所有格式设置值，并确保每个人在签入其代码之前都运行该格式设置器。如果我们想要更加严格，可以为版本控制系统添加一个提交钩子，以在代码被接受之前缩进代码。

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

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

我工作的商店没有统一的编码标准，我可以说我们(作为一个团队)深受其苦。当个人没有意愿时(例如在我的一些同事的情况下)，团队负责人必须在桌上敲拳，并施加某种形式的标准化编码准则。

曾经的语言都有社区使用的通用标准。我们应该尽可能地遵循这些规定，以便其他惯用该语言的人可以维护代码，但是无需对其进行独裁。

正式标准的创建是错误的，因为公司编码标准通常过于僵化，无法使用该语言与普通社区交流。

如果我们确实对团队成员存在编码风格的问题，那么对于团队来说，在编码评审中轻轻地提出建议不是一个好主意，这是一件好事。

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

样式标准：NO。可读性是我迷惑的垃圾，反之亦然。良好的注释和代码分解具有更大的好处。也gnu缩进。

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

我完全同意应该应用编码标准，并且几乎应该始终在团队级别上使用。但是，有几个例外。

如果团队正在编写供其他团队使用的代码(在这里我的意思是其他团队将不得不查看源代码，而不仅仅是将其用作库)，那么在所有团队之间制定通用标准会有所裨益使用它。同样，如果公司的政策是频繁将程序员从一个团队转移到另一个团队，或者某个团队经常想重用另一个团队的代码，那么最好在整个公司内强加​​标准。

就像其他人提到的那样，我认为这需要通过工程或者团队来进行-公司(即业务部门)不应参与此类决策。

但是我要补充的另一件事是，任何实施的规则都应该由工具而不是人员来实施。 IMO最坏的情况是过于狂热的语法势头(是的，我们存在；我知道因为我们能闻到自己的味道)写了一些文档，概述了一组编码指南，但实际上没有人真正阅读或者遵循。随着时间的推移，它们变得过时，随着新人加入团队而老人们离开，他们变得陈旧。

然后，出现了一些冲突，使某个人处于不得不面对其他人的编码风格的不舒服位置上-这种冲突应该由工具而不是由人来完成。简而言之，在我看来，这种强制执行方法是最不希望的，因为它太容易被忽略，并且只是乞求程序员来讨论愚蠢的事情。

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

无论是用于设计还是开发，样式指南都非常重要，因为它们可以加快协作人员(甚至是单独或者顺序地工作，就像在接管旧项目时一样)的沟通和绩效。公司内部没有约定俗成的制度，只是在要求人们尽可能地降低生产力。大多数项目都需要协作，即使那些并非如此的项目也可能不容易受到我们天生渴望行使编程能力并保持最新状态的渴望。我们对学习的渴望阻碍了我们的一致性，这本身就是一件好事，但是却会使新员工疯狂地尝试学习他们正在使用的系统。

与其他任何旨在善恶而不是邪恶的系统一样，该指南的真正力量在于其人员的手中。开发人员自己将确定什么是必不可少的有用部分，然后希望使用它们。

喜欢法律。或者英语。

如果在头脑风暴会议上出现了风格指导，则它应该尽可能地深入，应将其包括在内。我们对问题的措辞很奇怪，因为在一天结束时，由于只有一个GUIDE，所以无法"强加"一个样式指南。

RTFM，然后收集好东西并继续进行。

我不认为开发团队应该有必须遵循的风格指导原则。有一些例外情况，例如在#include语句中使用<>与""的情况，但这些例外情况应视需要而定。

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

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

...当他们习惯看到以下内容时：

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

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

最终，如果Joe退后了10分钟的时间并移动花括号，以便Bill可以少花3秒钟的时间查看代码，那么是否真的节省了任何时间使Bill做他不自然的事情？

有两种类型的约定。

A类约定："请执行这些操作，这会更好"

和类型B："请在路的右侧驾驶"，但可以在另一侧驾驶，只要每个人都以相同的方式行驶即可。

没有一个独立的团队。一个好的公司中的所有代码都以某种方式连接在一起，并且样式应该保持一致。使自己习惯一种新样式要比适应二十种不同的样式容易。

另外，新开发人员应该能够尊重并遵守现有代码库的惯例。