根据McCall的质量模型，产品修订版是描述软件产品的质量属性的三个主要观点之一。从产品修订版的角度来看，可维护性(发现和修复缺陷的能力)被认为是影响软件修订能力的关键质量因素。

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

我们与哪些通用语言无关的代码格式化指南一起使用，以使程序员在代码修订过程中的效率和有效性最大化？

解决方案

回答

我曾经使用过的最佳指南是一致性。多年来，我在不同的团队中使用了许多不同的样式...最好的结果是，当整个团队被迫使用相同的样式时，无论它是什么样式:-)

回答

我同意乔尔。那里有很多风格的例子。大部分都很好。有些不再有用(匈牙利表示法？)。重点是一致性。只要一个新的开发人员可以立即进入并理解代码，而不必习惯每个开发人员的个人风格，它就可以工作。

每年左右转换标准可能不是一个好主意。

回答

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

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

回答

我同意Joel的观点，当组织内部保持一致时，可维护性将大大提高。如果我加入另一个团队，那么如果一切都与我的当前版本具有相似的外观，则加速时间将大大减少，因为我可以在不进行所有"内部上下文切换"的情况下更快地读取代码，以使自己"摆脱困境"，以便他们使用mVar而不是_var" /等

回答

我对某些语言不可知的概念有一些想法：

1.)删除无效代码。除非绝对必要，否则应删除已注释掉的无效代码。它使例程杂乱无章，当我们搜索某些字符串时，我们常常会得到误报，并且它显示出粗俗的外观，这对专业开发人员不利。

2.)有关维护修补程序，请在注释中引用缺陷跟踪编号-假设我们具有某种缺陷跟踪系统。这使维护工作的任何人都更容易弄清楚为什么在一个修订版和另一个修订版之间更改了代码。

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

我敢肯定还有其他一些与语言无关的概念，但这是我想到的头几个概念。据我所知，在缺少特定语言的情况下讨论编码标准相对困难。我同意上面的其他答复-最好的样式通常是与现有样式最无缝融合的样式。

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

回答

我们拥有的一项伟大标准是变量"前缀"。直到我来到这里，我基本上都是独自写歌，所以我不用担心。

我们"必须"使用前缀来表示变量的名称。因此，当我们查看dpVarName时，立即知道它是一个指向double的指针，而lVarName是一个long int。

起初，我很高兴他们给了我们两种选择，以括号为单位，但是现在我希望我们都被迫以一种或者另一种方式来做。