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

Question

根据 麦考尔的质量模型, 产品改版 是描述软件产品质量属性的三个主要视角之一。从产品修订的角度来看， 可维护性, 发现并修复缺陷的能力, ，被认为是影响修改软件能力的关键质量因素。

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

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

Answer 1

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

Answer 2

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

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

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

3.) 对于支持它的语言，声明变量时应尽可能接近其首次使用。

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

您可能想看看史蒂夫·麦康奈尔的 代码完成. 。它充满了好主意，无论编程语言如何，它们都应该适用于几乎任何开发情况。

Answer 3

一致性是关键。将准则写在某处，并要求遵守。

代码格式不值得担心，也不值得争论。只需制定一些规则并遵守它们即可。

Answer 4

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

大约每年更换一次标准可能是一个坏主意。

Answer 5

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

Answer 6

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

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

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