7,763
社区成员
发帖
与我相关
我的任务
分享请大侠们提供一个代码质量评定标准
今天让几个同事完成了一个简单项目，想得到一个报告，评定他们谁比较优秀，比如使用新技术的程度，变量命名的好坏等，现在想到的评定项目太少了，不知道大家是怎么评定的呢，请给我提供一份吧参考吧
每千行程序20个错误以下（包含20个）
每千行程序21-25个错误
每千行程序26-30个错误
每千行程序31-35个错误
每千行程序36个错误以上（包含36个）
大量使用新技术，并且解决了传统技术无法解决的问题
大量使用新技术，解决了传统技术难以解决的问题，大大提高了工作效率
使用部分新技术，替代了部分传统技术，一定程度上提高了工作效率
使用了少量的新技术，替代了了少量的传统技术
没有使用任何新技术，仍然用传统技术解决问题
编码非常规范，无可挑剔，同时又对公司制度规范提出了改进意见
编码非常规范，无可挑剔
编码规范，不符合规范之处很少
编码基本规范，但不影响对程序的理解
编码存在较大的不规范性，并且对程序理解造成了比较严重理解误差
请知道的补充一下哈
油箱：zou_seafarer@hotmail.com
每千行程序20个错误以下（包含20个）
每千行程序21-25个错误
每千行程序26-30个错误
每千行程序31-35个错误
每千行程序36个错误以上（包含36个）
大量使用新技术，并且解决了传统技术无法解决的问题
大量使用新技术，解决了传统技术难以解决的问题，大大提高了工作效率
使用部分新技术，替代了部分传统技术，一定程度上提高了工作效率
使用了少量的新技术，替代了了少量的传统技术
没有使用任何新技术，仍然用传统技术解决问题
编码非常规范，无可挑剔，同时又对公司制度规范提出了改进意见
编码非常规范，无可挑剔
编码规范，不符合规范之处很少
编码基本规范，但不影响对程序的理解
编码存在较大的不规范性，并且对程序理解造成了比较严重理解误差
请知道的补充一下哈
油箱：zou_seafarer@hotmail.com
...全文
请发表友善的回复…
发表回复
ZOU_SEAFARER 2007-11-14
- 打赏
- 举报
==============
ZOU_SEAFARER 2007-10-26
- 打赏
- 举报
哎……
用这些来评的话，我只得出一个结论。
一行代码不写，那人就是最优秀的。尽管他可能不会写代码。
======================================================================
判定的前提当然是 功能的实现
如果没有一个代码，你觉得还适合去判定一个程序，一个人么？
用这些来评的话，我只得出一个结论。
一行代码不写，那人就是最优秀的。尽管他可能不会写代码。
======================================================================
判定的前提当然是 功能的实现
如果没有一个代码，你觉得还适合去判定一个程序，一个人么？
tianhuo_soft 2007-10-26
- 打赏
- 举报
可以参照 北大出 《软件质量标准》
vansoft 2007-10-26
- 打赏
- 举报
哎……
用这些来评的话，我只得出一个结论。
一行代码不写，那人就是最优秀的。尽管他可能不会写代码。
用这些来评的话，我只得出一个结论。
一行代码不写，那人就是最优秀的。尽管他可能不会写代码。
beal_p 2007-10-26
- 打赏
- 举报
还有代码的可读性、可维护性、及可扩展性
ZOU_SEAFARER 2007-10-25
- 打赏
- 举报
归根结底，对程序员进行评定，只要：
① 前提：按规范执行。
② 比较犯错的次数与严重度。
③ 完成工作的效率。
④ 协作精神、互助精神等等其它的非量化指标。
就是这个规范不好制定，现在就是想用规范去约束程序员，不让他们随意发挥，因为如果随意发挥的话，工程质量，以及最后的纳期如何保证，发挥可以，不个要服从大局！
ZOU_SEAFARER 2007-10-25
- 打赏
- 举报
theforever 碧海青天
实际上，作为有经验的程序员，通过看其他程序员的代码错误，基本上就可以对那个程序员的性格和工作态度有个了解=========================================================================================
通过看代码错误 就能看出一个程序员的工作态度，碧海青天 说的代码错误指那个方面〉如果是语法方面的话，代码模块在上交主管人员前肯定经过了模块测试，那么这样语法错误基本就没有办法知道
如果是逻辑错误的话，如果程序元不知道，主管人员没有经过系统的测试也未必能看到他的错误，即便知道了他有这个错误存在，也只是看到效果，表面的错误（输入不符合预期），这样也未必能知道代码中错误所在，这样的错误应该怎么去评定呢？
如果自己是主管人员的话，下面程序员写的代码都是按照流程图来写程序的，自己有熟悉流程，所以程序的易读就很不好判定了
再加上人为的感情色彩，生活习性了解，基本没有障碍！这样又怎么去判定程序员的代码是否易懂呢？
实际上，作为有经验的程序员，通过看其他程序员的代码错误，基本上就可以对那个程序员的性格和工作态度有个了解=========================================================================================
通过看代码错误 就能看出一个程序员的工作态度，碧海青天 说的代码错误指那个方面〉如果是语法方面的话，代码模块在上交主管人员前肯定经过了模块测试，那么这样语法错误基本就没有办法知道
如果是逻辑错误的话，如果程序元不知道，主管人员没有经过系统的测试也未必能看到他的错误，即便知道了他有这个错误存在，也只是看到效果，表面的错误（输入不符合预期），这样也未必能知道代码中错误所在，这样的错误应该怎么去评定呢？
如果自己是主管人员的话，下面程序员写的代码都是按照流程图来写程序的，自己有熟悉流程，所以程序的易读就很不好判定了
再加上人为的感情色彩，生活习性了解，基本没有障碍！这样又怎么去判定程序员的代码是否易懂呢？
ZOU_SEAFARER 2007-10-25
- 打赏
- 举报
下面有我参考别人的经验，自己增加了点东西
来作为硬性标准，希望大家继续提供宝贵意见，
人员 工作能力 工作效率
开发人员
工作能力
============================
使用开发语言的能力
使用开发工具的能力
写程序设计文档的能力
规定纳期完成任务能力
工作内时间完成任务能力
实际解决解决问题能力
协同完成工作能力
语言/沟通能力
临时工作分配完成能力
对开发项目的理解能力
工作效率
==========================================
代码编写效率
处理疑难问题的效率
文档编写效率
新知识接受效率
其他工作任务完成效率
工作质量
============================================
开发出的代码错误少
开发出的代码容易维护（模块化、容易读、有注释）
程序设计文档的质量
程序中算法质量
开发出的代码BUG数量少
其他工作完成质量
这个是在工作上，业务上的一些建议列举，谢谢大家
听说华为人事有一套不错的评定标准，不知道这里有兄弟手上有这个资料么？？
来作为硬性标准，希望大家继续提供宝贵意见，
人员 工作能力 工作效率
开发人员
工作能力
============================
使用开发语言的能力
使用开发工具的能力
写程序设计文档的能力
规定纳期完成任务能力
工作内时间完成任务能力
实际解决解决问题能力
协同完成工作能力
语言/沟通能力
临时工作分配完成能力
对开发项目的理解能力
工作效率
==========================================
代码编写效率
处理疑难问题的效率
文档编写效率
新知识接受效率
其他工作任务完成效率
工作质量
============================================
开发出的代码错误少
开发出的代码容易维护（模块化、容易读、有注释）
程序设计文档的质量
程序中算法质量
开发出的代码BUG数量少
其他工作完成质量
这个是在工作上，业务上的一些建议列举，谢谢大家
听说华为人事有一套不错的评定标准，不知道这里有兄弟手上有这个资料么？？
ZOU_SEAFARER 2007-10-25
- 打赏
- 举报
另外，我觉得程序的性能效率是一个必须考虑的重要问题。
=====================================================================
这个效率方面我觉得没有比较如何知道效率多少？
对于一个项目，谁都不可能做2分一样的开发，也不会安排2个人作同样的工作，要看效率我想无非就是查看代码里面的一些技巧，以及一些大工作量的代码处理方式，但是没有一个标准，怎么评定？
=====================================================================
这个效率方面我觉得没有比较如何知道效率多少？
对于一个项目，谁都不可能做2分一样的开发，也不会安排2个人作同样的工作，要看效率我想无非就是查看代码里面的一些技巧，以及一些大工作量的代码处理方式，但是没有一个标准，怎么评定？
tubo_true 2007-10-08
- 打赏
- 举报
look
jjfwenwenti 2007-10-07
- 打赏
- 举报
学习
colorslife 2007-10-02
- 打赏
- 举报
to:fj182(阿花),判断程序是否在IDE下运行,只要判断App.LogMode是否为0就可以了,为1就表示编译好了的程序,不过你那第二种方法确实巧妙啊,呵呵
clear_zero 2007-10-01
- 打赏
- 举报
好贴
我觉得很难用一个统一的规范来看代码质量
我们的目的是多人协作完整一个软件，最终变成效益。
一个人的代码如何最方便得让其他人阅读，接手非常重要。其实这个很忽略程序员个人风格的
命名规则主要还是看公司的标准，这样就可以统一了。方便其他人阅读就可以了
程序注解要写，辅助文档要全
代码出错不要紧，但是要抓错。error handle的习惯非常重要
写代码要有全局感，领导对全局地把握非常重要。直接影响到代码的复用率。
具体到每个程序员来说，在写代码的时候要为将来拓展打基础，代码的可读性非常重要。有些看似聪明的点，当程序作大，函数功能便多的时候那些点可能就成为代码快速更新的障碍
新技术这个问题就麻烦了，只能说在合适的问题上用到了合适的技术点
对于程序员的评判还是那些非线性的标准占主导。
我觉得很难用一个统一的规范来看代码质量
我们的目的是多人协作完整一个软件，最终变成效益。
一个人的代码如何最方便得让其他人阅读，接手非常重要。其实这个很忽略程序员个人风格的
命名规则主要还是看公司的标准，这样就可以统一了。方便其他人阅读就可以了
程序注解要写，辅助文档要全
代码出错不要紧，但是要抓错。error handle的习惯非常重要
写代码要有全局感，领导对全局地把握非常重要。直接影响到代码的复用率。
具体到每个程序员来说，在写代码的时候要为将来拓展打基础，代码的可读性非常重要。有些看似聪明的点，当程序作大，函数功能便多的时候那些点可能就成为代码快速更新的障碍
新技术这个问题就麻烦了，只能说在合适的问题上用到了合适的技术点
对于程序员的评判还是那些非线性的标准占主导。
Tiger_Zhao 2007-09-28
- 打赏
- 举报
theforever(碧海情天) 所说的各种错误其实都属于规范中必须定义的内容。
规范只是划出一条及格线，如果有人没达标，必须重做或修正，否则项目不算完成。
只有在及格之后，才能进行其它的考评。
“新技术”通常不应该作为考评依据，越是“新技术”，其使用风险越大－－程序是人编的，是人总会犯错，而“新技术”恰恰缺少大量用户的使用而比“老技术”隐藏更多错误。使用何种技术应该在项目架构时经过论证后决定，绝对不能放任普通程序员自由发挥。
“性能”其实也不是很重要的考评依据，因为需求说明或规范中必须对性能要求有描述，如果要求 1 秒内完成，用时 0.5 秒或 0.1 秒其实并不重要，在达标的前提下，代码的易读性、可维护性其实更重要。其实大家都有体会，对代码进行优化后，常常代码量变大、不易阅读、不易调试。所以在算法性能上，只要测试达标，同行评审一下没有犯将 O(n) 复杂度变成 O(n^2) 之类的错误就可以了。
归根结底，对程序员进行评定，只要：
① 前提：按规范执行。
② 比较犯错的次数与严重度。
③ 完成工作的效率。
④ 协作精神、互助精神等等其它的非量化指标。
规范只是划出一条及格线，如果有人没达标，必须重做或修正，否则项目不算完成。
只有在及格之后，才能进行其它的考评。
“新技术”通常不应该作为考评依据，越是“新技术”，其使用风险越大－－程序是人编的，是人总会犯错，而“新技术”恰恰缺少大量用户的使用而比“老技术”隐藏更多错误。使用何种技术应该在项目架构时经过论证后决定，绝对不能放任普通程序员自由发挥。
“性能”其实也不是很重要的考评依据，因为需求说明或规范中必须对性能要求有描述，如果要求 1 秒内完成，用时 0.5 秒或 0.1 秒其实并不重要，在达标的前提下，代码的易读性、可维护性其实更重要。其实大家都有体会，对代码进行优化后，常常代码量变大、不易阅读、不易调试。所以在算法性能上，只要测试达标，同行评审一下没有犯将 O(n) 复杂度变成 O(n^2) 之类的错误就可以了。
归根结底，对程序员进行评定，只要：
① 前提：按规范执行。
② 比较犯错的次数与严重度。
③ 完成工作的效率。
④ 协作精神、互助精神等等其它的非量化指标。
rjzhangjun 2007-09-27
- 打赏
- 举报
哇我看出来了.不要判断嘛..哈哈哈....你们真有趣..我也顶
dim b as boolean
.
.
.
text1.enabled =b
text2.enabled =b
.
.
.
dim b as boolean
.
.
.
text1.enabled =b
text2.enabled =b
.
.
.
fj182 2007-09-27
- 打赏
- 举报
说起新技术，我这有个例子。
' 判断程序是否在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
看起来第一种方法要时髦一点，不过就为这一点功能就加一个库好像有点划不来，感觉有点鸡肋。
' 判断程序是否在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
看起来第一种方法要时髦一点，不过就为这一点功能就加一个库好像有点划不来，感觉有点鸡肋。
碧海情天-赵亮 2007-09-27
- 打赏
- 举报
讨论编码规范性，首先要看公司的规范和程序员本人的规范是否相同，并且是否先让程序员了解学习公司的规范。因为编码规范并非唯一的。
另外，我觉得程序的性能效率是一个必须考虑的重要问题。这个反倒没有看到提及。正确地实现功能，是编程的一个保底要求，而实现得好坏（整体逻辑地安排，控件元件地运用，语句的精练易懂）才体现了更高程度上的水平。如果说“新技术”难以评定一个程序员的好坏，那么一个３秒的查询肯定比一个３０秒的查询说明问题（即使后者使用了天花乱坠的新技术）。
另外，我觉得程序的性能效率是一个必须考虑的重要问题。这个反倒没有看到提及。正确地实现功能，是编程的一个保底要求，而实现得好坏（整体逻辑地安排，控件元件地运用，语句的精练易懂）才体现了更高程度上的水平。如果说“新技术”难以评定一个程序员的好坏，那么一个３秒的查询肯定比一个３０秒的查询说明问题（即使后者使用了天花乱坠的新技术）。
碧海情天-赵亮 2007-09-27
- 打赏
- 举报
至于错误，也不应只简单地以个数评定。而应该区分错误的类别。
毫无疑问，逻辑上的错误应该是最严重的错误。尤其是那些运行起来根本不会报错的错误，它们是潜在的最大隐患。
而那些函数名称错误，只能说是一种粗心的麻烦，只要一运行，编译器就会指出来。
实际上，作为有经验的程序员，通过看其他程序员的代码错误，基本上就可以对那个程序员的性格和工作态度有个了解。
毫无疑问，逻辑上的错误应该是最严重的错误。尤其是那些运行起来根本不会报错的错误，它们是潜在的最大隐患。
而那些函数名称错误，只能说是一种粗心的麻烦，只要一运行，编译器就会指出来。
实际上，作为有经验的程序员，通过看其他程序员的代码错误，基本上就可以对那个程序员的性格和工作态度有个了解。
碧海情天-赵亮 2007-09-27
- 打赏
- 举报
所谓使用新技术，这个很值得商榷。
１、新技术总是有针对性的。并非所有领域、所有项目都需要追逐新技术。
２、一个能力更好的程序员，可能任务量也更多，于是就没有时间主动学习新技术，除非公司专门下达学习新技术的任务。
３、闻道有前后，由于天赋和其它诸多因素，修炼几十年也未必如一朝顿悟，所以先闻道者不一定就优秀，后闻道者不一定就相对差，这只是各人的时机的问题。四年级末等生也肯定比三年级优等生多知道几个名词概念。
衡量对于新技术的掌握能力，正确的方式应该是把一种新技术的详细材料给几个程序员看（即使他们中有人已经掌握），然后看他们的掌握效果（效果相同再看速度）。简单地说，就是要在一个起跑线上比较。忽略客观现实闻道先后，这是普遍都会犯的一个巨大的错误！
１、新技术总是有针对性的。并非所有领域、所有项目都需要追逐新技术。
２、一个能力更好的程序员，可能任务量也更多，于是就没有时间主动学习新技术，除非公司专门下达学习新技术的任务。
３、闻道有前后，由于天赋和其它诸多因素，修炼几十年也未必如一朝顿悟，所以先闻道者不一定就优秀，后闻道者不一定就相对差，这只是各人的时机的问题。四年级末等生也肯定比三年级优等生多知道几个名词概念。
衡量对于新技术的掌握能力，正确的方式应该是把一种新技术的详细材料给几个程序员看（即使他们中有人已经掌握），然后看他们的掌握效果（效果相同再看速度）。简单地说，就是要在一个起跑线上比较。忽略客观现实闻道先后，这是普遍都会犯的一个巨大的错误！
Tiger_Zhao 2007-09-26
- 打赏
- 举报
规章制度是项目开展的前提！！！
只有明确制度的情况下，才能逐条进行量化考核。
如果连规章制度都没有，要项目经理做什么？
如果没有交通法规，逆行、抢道、酒后驾车都是可以的，那么怎么来评定两名司机的好坏？
daisy8675(莫依)说五个人能写出二十多种写法，在有严格规章制度的情况下根本不可能。一个项目内的代码只能是一种风格，人与人的差异仅仅在选用算法上可能不同，这可以通过同行评审和测试进行考核。
总之没有规矩就没有方圆，没有规章制度就没有考核。
只有明确制度的情况下，才能逐条进行量化考核。
如果连规章制度都没有，要项目经理做什么？
如果没有交通法规，逆行、抢道、酒后驾车都是可以的，那么怎么来评定两名司机的好坏？
daisy8675(莫依)说五个人能写出二十多种写法，在有严格规章制度的情况下根本不可能。一个项目内的代码只能是一种风格，人与人的差异仅仅在选用算法上可能不同，这可以通过同行评审和测试进行考核。
总之没有规矩就没有方圆，没有规章制度就没有考核。
加载更多回复（15）
