请大侠们提供一个代码质量评定标准
今天让几个同事完成了一个简单项目，想得到一个报告，评定他们谁比较优秀，比如使用新技术的程度，变量命名的好坏等，现在想到的评定项目太少了，不知道大家是怎么评定的呢，请给我提供一份吧参考吧
每千行程序20个错误以下（包含20个）
每千行程序21-25个错误
每千行程序26-30个错误
每千行程序31-35个错误
每千行程序36个错误以上（包含36个）
大量使用新技术，并且解决了传统技术无法解决的问题
大量使用新技术，解决了传统技术难以解决的问题，大大提高了工作效率
使用部分新技术，替代了部分传统技术，一定程度上提高了工作效率
使用了少量的新技术，替代了了少量的传统技术
没有使用任何新技术，仍然用传统技术解决问题
编码非常规范，无可挑剔，同时又对公司制度规范提出了改进意见
编码非常规范，无可挑剔
编码规范，不符合规范之处很少
编码基本规范，但不影响对程序的理解
编码存在较大的不规范性，并且对程序理解造成了比较严重理解误差
请知道的补充一下哈
油箱：zou_seafarer@hotmail.com
[解决办法]
与项目的类别,规模都有关系,不同的评定者标准肯定不同,搜来的:
A. 可以量化的最基本的方面包括[ancor:基本量化]：
一份代码文件的长度；一个package包含的class的个数；一个class包含的method的个数；一个method包含的逻辑分支（if, else, switch, loop）的个数；一个逻辑分支的嵌套深度；一个method signature包含的参数个数；一个class的代码行数；一个method的代码行数；代码行能否明确地设置每一个操作指令的调试断点；等等。
B. 还包括一些更高级的方面：
method之间是否存在交叉引用；class之间是否存在交叉引用；package之间是否存在交叉引用；是否所有的递归调用都是同一个method调用自己；Object之间的交叉引用是否都控制在interface里面，而不是具体的类里面；增加新功能，是否需要修改原有的代码，还是只需要增加新的class代码就可以；一个class的多个method之间是否存在调用顺序；一个class拥有多少个可变属性，这些属性在使用中，需要被设置几次；等等。
参考: http://www.agiletao.com/simple/index.php?t286.html
[解决办法]
每千行程序20个错误以下（包含20个）
每千行程序21-25个错误
每千行程序26-30个错误
每千行程序31-35个错误
每千行程序36个错误以上（包含36个）
这些可以细化，应该针对于bug分级，例如程序挂掉的是A级，和预期结果不一致的是B级，有效率问题为C级，操作不方便的为D级等
AB级bug对于程序是致命的
另外还要考虑代码的封装和组件化的考虑，这很重要
[解决办法]
说实在话，挺难的，因为我至今接触过大陆这边的代码，五个人能写出二十多种写法。
关于代码质量，我更看重的是思路的清晰，那怕代码的量会更多。
注释的简洁。
还有一个就是质量管理中间，是否对整个过程中每个环节有详细的跟踪记录处理。
[解决办法]
这个好像很难的，我的想法是找一个和A水平差不多的程序员B，让B去读A的程序，看看B是否很容易就能读懂，能很快读懂的话说明A所写程序的风格很规范。至于代码原则什么的那是死套路吧，很好搞。
查看错误数量我不是很明白，如果一边写一部分代码就进行一次调试，那最后怎么知道每千行有多少错误？难道每次调试要把错误数记下来？笔误也算？
[解决办法]
我也来凑个热闹。
经常看到经验丰富的老程序员写的类似代码，如：
dim b as boolean
if b = true then
...
end if
或者：
dim b as boolean
if b = true then
text1.enabled = true
text2.enabled = true
else
text1.enabled = false
text2.enabled = false
end if
[解决办法]
规章制度是项目开展的前提！！！
只有明确制度的情况下，才能逐条进行量化考核。
如果连规章制度都没有，要项目经理做什么？
如果没有交通法规，逆行、抢道、酒后驾车都是可以的，那么怎么来评定两名司机的好坏？
daisy8675(莫依)说五个人能写出二十多种写法，在有严格规章制度的情况下根本不可能。一个项目内的代码只能是一种风格，人与人的差异仅仅在选用算法上可能不同，这可以通过同行评审和测试进行考核。
总之没有规矩就没有方圆，没有规章制度就没有考核。
[解决办法]
所谓使用新技术，这个很值得商榷。
１、新技术总是有针对性的。并非所有领域、所有项目都需要追逐新技术。
２、一个能力更好的程序员，可能任务量也更多，于是就没有时间主动学习新技术，除非公司专门下达学习新技术的任务。
３、闻道有前后，由于天赋和其它诸多因素，修炼几十年也未必如一朝顿悟，所以先闻道者不一定就优秀，后闻道者不一定就相对差，这只是各人的时机的问题。四年级末等生也肯定比三年级优等生多知道几个名词概念。
衡量对于新技术的掌握能力，正确的方式应该是把一种新技术的详细材料给几个程序员看（即使他们中有人已经掌握），然后看他们的掌握效果（效果相同再看速度）。简单地说，就是要在一个起跑线上比较。忽略客观现实闻道先后，这是普遍都会犯的一个巨大的错误！
[解决办法]
讨论编码规范性，首先要看公司的规范和程序员本人的规范是否相同，并且是否先让程序员了解学习公司的规范。因为编码规范并非唯一的。
另外，我觉得程序的性能效率是一个必须考虑的重要问题。这个反倒没有看到提及。正确地实现功能，是编程的一个保底要求，而实现得好坏（整体逻辑地安排，控件元件地运用，语句的精练易懂）才体现了更高程度上的水平。如果说“新技术”难以评定一个程序员的好坏，那么一个３秒的查询肯定比一个３０秒的查询说明问题（即使后者使用了天花乱坠的新技术）。
[解决办法]
说起新技术，我这有个例子。
' 判断程序是否在IDE下运行，如果是则返回True,否则返回False
' 貌似比较新的技术（需要引用 TLI）
public function InIDE() as boolean
InIDE = (InterfaceInfoFromObject(App).Name = "_App ")
end function
' 这是传统的版本
public function InIDE() as boolean
on error resume next
debug.print 1/0
InIDE =(err.number <> 0)
end function
看起来第一种方法要时髦一点，不过就为这一点功能就加一个库好像有点划不来，感觉有点鸡肋。
[解决办法]
好贴
我觉得很难用一个统一的规范来看代码质量
我们的目的是多人协作完整一个软件，最终变成效益。
一个人的代码如何最方便得让其他人阅读，接手非常重要。其实这个很忽略程序员个人风格的
命名规则主要还是看公司的标准，这样就可以统一了。方便其他人阅读就可以了
程序注解要写，辅助文档要全
代码出错不要紧，但是要抓错。error handle的习惯非常重要
写代码要有全局感，领导对全局地把握非常重要。直接影响到代码的复用率。
具体到每个程序员来说，在写代码的时候要为将来拓展打基础，代码的可读性非常重要。有些看似聪明的点，当程序作大，函数功能便多的时候那些点可能就成为代码快速更新的障碍
新技术这个问题就麻烦了，只能说在合适的问题上用到了合适的技术点
对于程序员的评判还是那些非线性的标准占主导。
