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

Question

根据McCall 的质量模型，产品修订是描述软件产品质量属性的三个主要视角之一。在产品修订的角度下，可维护性，即发现和修复缺陷的能力，被确定为影响软件修订能力的关键质量因素。

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

您使用过哪些普遍接受的、与语言无关的代码格式指南，可以最大限度地提高程序员在代码修订过程中的效率和有效性？

Answer 1

我用过的最好的指导方针是一致性。多年来，我在不同的团队中使用了很多不同的风格......我见过的最好的结果是当整个团队被迫使用相同的风格时，不管它是什么风格:-)

Answer 2

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

1.) 删除死代码。除非某些东西是绝对必要的、被注释掉的，否则应该删除死代码。它使例行程序变得混乱，当您搜索某些字符串时，您经常会得到误报，并且它显示出对专业开发人员不利的普遍草率

2.) 对于维护修复，请在评论中引用缺陷跟踪号——假设您有某种缺陷跟踪系统。这使任何维护您的工作的人更容易弄清楚为什么代码在一个版本和另一个版本之间发生了更改。

3.) 对于支持它的语言，声明变量尽可能接近它们的第一次使用。

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

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

Answer 3

一致性是关键。在某处写下指导方针，并要求遵守。

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

Answer 4

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

每年左右更换标准可能是个坏主意。

Answer 5

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

Answer 6

我们拥有的伟大标准之一是可变的“前缀”。在我来到这里之前，我大部分时间都是独自写作，所以我并不担心。

我们“被要求”用前缀来命名变量，这些前缀表明它们是什么。因此，当您查看 dpVarName 时，您会立即知道它是一个指向 double 的指针，而 lVarName 是一个 long int。

起初我很高兴他们给了我们两种包围块的选择，但现在我希望我们都被迫以一种或另一种方式去做。