最近，我看到Microsoft发布了编码标准文档（“多合一编码框架编码标准”），这让我开始思考...我工作的公司根本没有正式的编码标准。仅有几个开发人员，我们在一起的时间已经足够长，已经演变成类似的样式，这从来都不是问题。
您工作的公司是否有书面的编码标准？如果没有，为什么不呢？有标准会有所作为吗？是否值得从头开始编写标准，还是应该采用其他标准作为自己的标准（即使Microsoft的标准成为您的标准）？
Answers:
对于团队来说，为每种语言制定单一的编码标准很重要，这样可以避免几个问题：
- 让它们在前几次迭代中进化。
- 让他们特定于团队而不是特定于公司。
- 如果可以避免，请不要写下来。相反，让代码成为捕获标准的方式。
- 不要立法好的设计。（例如，不要告诉人们不要使用goto）
- 确保每个人都知道该标准与通信有关，而别无其他。
- 经过最初的几次迭代后，请团队共同决定。
我认为有一个编码标准是至关重要的，即使它说的只是“我们使用3空格缩进，并且在下一行使用开括号”。一些好处：
就是否采用现有标准而言，没有关系-一致性很重要。如果您的开发人员有十几种不同的样式，则不妨选择一个现有的，已发布的样式。如果您都进化成了一种非常一致的样式，只需写下来并使用它。
不幸的是没有。因此，每个人都有使用间距，缩进等的自己的方式，所有东西都混合在一起了（这样，我们甚至不必使用“怪”功能就可以知道谁是代码行的作者！）
但是，甚至更糟的是，有人用意大利语写变量和类名，其他人用英语写...
我总是根据我使用的语言，库和框架来调整样式，以使源代码看起来统一而朴素。
请记住，这是特定于多合一代码框架的编码标准文档。
我曾在多家公司工作，其中一些公司拥有现有的标准，而某些（大多数）我曾帮助开发该标准。在大多数情况下，如果您正在进行基于.NET的开发（即使您并非这样做，大多数规则仍然适用），则应查看Framework Design Guidelines。尽管这是特定于编写面向公众的API，但大多数准则同样适用于任何代码。
代码标准最大的问题是保持代码相对简单和直接。您希望开发人员能够对所提供的准则进行内部化，因此给他们50页以上的文档毫无用处。如果您想提供背景，示例等，您仍然可以创建该文档，但是您还需要一些归结为一组项目符号准则的内容。您的编码标准还必须是灵活的，实时的文档，该文档需要随着技术的变化而变化。
我们是blub商店，因此我们使用blub编程约定。
现在，Paul Graham和朋友比我们聪明得多，但我们的blub程序员，我们都能互相阅读blub，实际上，任何blub程序员都可以阅读我们的blub代码。
实际上，由于blub的设计，任何blub程序员都可以读取任何单个blub文件并理解该文件，因为blub没有宏系统。
如果我们使用C或C ++进行编程（即使我们使用blub编程，我们都是多语言的），但对于新代码或开源项目（我们正在使用的项目的标准），我们大多使用blub风格。