什么是普遍接受的代码格式指南？

Question

根据McCall's Quality Model，产品修订是描述软件产品质量属性的三个主要观点之一。在“产品修订”视角下，可维护性，查找和修复缺陷的能力被识别为影响修改软件能力的关键品质因素。

显然，在修订过程的某个阶段，需要人为参与，特别是程序员的参与。代码的格式化会影响程序员有效和高效地修改软件的能力。

您使用哪种语言无关的代码格式化指南，以便在代码修订过程中最大限度地提高程序员的效率和效率？

Answer 1

我曾经使用的最佳指导方针是一致性。多年来我用不同的团队使用了很多不同的风格...我看到的最好的结果是整个团队被迫使用相同的风格，无论它是什么样式： - ）

Answer 2

我对一些与语言无关的概念有一些想法：

1。）删除死代码。除非某些内容绝对必要，否则应删除已删除的代码。它会使一个例程变得混乱，当你搜索一些字符串时，你经常会得到误报，并且它显示出对专业开发人员不利的普遍邋iness

2.。）对于维护修复，请在评论中引用缺陷跟踪编号 - 假设您有某种缺陷跟踪系统。这使得维护您工作的任何人都可以更轻松地找出代码在一个修订版和另一个修订版之间的更改原因。

3.）对于支持它的语言，请尽可能将变量声明为第一次使用。

我确信还有一些与语言无关的概念，但这些是我想到的最初几个概念。据我所知，在没有特定语言的情况下讨论编码标准相对困难。我同意上面的其他回复 - 最好的风格通常是与现有风格最无缝融合的风格。

您可能需要查看Steve McConnell的 Code Complete 。它充满了好的想法，几乎适用于任何开发环境，无论编程语言如何。

Answer 3

一致性是关键。在某处写下指南，并要求符合。

代码格式化不值得担心，也不会争论。只要制定一些规则，并坚持下去。

Answer 4

我同意乔尔。那里有很多风格的例子;大多数都很好。有些不再像其他人那样有用（匈牙利符号吗？）了。但重点是一致性。只要新开发人员可以立即进入并理解代码而不必习惯每个开发人员的个人风格，它就可以工作。

每年转换标准可能是一个坏主意。

Answer 5

我同意Joel的意见，当您的组织内部保持一致时，可维护性会大大提高。如果我加入另一个团队，如果所有内容都具有与我当前相似的外观和感觉，那么上升时间要少得多，因为我可以更快地读取代码，而不是所有的“内部上下文切换”以使我的头脑“让他们使用mVar而不是_var“/ etc

Answer 6

我们拥有的一个很好的标准是变量“前缀”。直到我来到这里，我大部分都是独自写作，所以我并不担心。

我们“需要”命名变量，前缀表示它们是什么。所以，当你看到dpVarName它是一个指向double的指针时，你立即知道，并且lVarName是一个long int。

我一开始很高兴他们给了我们两个包围块的选择，但现在我希望我们都被迫以某种方式做到这一点。