根据McCall的质量模型,产品修订是描述软件产品质量属性的三个主要观点之一.在"产品修订"的视角下,可维护性,查找和修复缺陷的能力被确定为影响修改软件能力的关键品质因素.
显然,在修订过程中的某个阶段,需要人为参与,特别是程序员的参与.代码的格式化会影响程序员有效和高效地修改软件的能力.
你曾经使用过哪些与语言无关的代码格式化指南,以便在代码修订过程中最大限度地提高程序员的效率和效率?
我曾经使用的最佳指导方针是一致性.多年来我使用了不同风格的不同团队......我见过的最好的结果是当整个团队被迫使用相同的风格时,无论它是什么样式:-)
我对一些与语言无关的概念有一些想法:
1.)删除死代码.除非某些内容绝对必要,否则应删除已删除的代码.它会使一个例程变得混乱,当你搜索一些字符串时,你经常会得到误报,并且它显示出对专业开发人员不利的普遍邋iness
2.)对于维护修复,请在注释中引用缺陷跟踪编号 - 假设您有某种缺陷跟踪系统.这使得任何维护您工作的人都可以更轻松地找出代码在一个修订版和另一个版本之间进行更改的原因.
3.)对于支持它的语言,声明变量尽可能接近它们的第一次使用.
我确信还有一些其他与语言无关的概念,但这些是我想到的最初几个.据我所知,在没有特定语言的情况下讨论编码标准相对困难.我同意上面的其他回复 - 最好的风格通常是与现有风格最无缝融合的风格.
您可能想看一下Steve McConnell的Code Complete.它充满了好的想法,几乎适用于任何开发情况,无论编程语言如何.