谈谈可读性在团队软件工程中的重要性--发表在公司黑板报的第二篇文章
2015-06-11 07:55
309 查看
尽管很多软件工程相关的书目、以及项目组平时的代码检视中都会提及代码可读的重要性,但在我们的实践中,代码可读依然没有得到足够的重视。可读性较差的代码会导致其读者(团队其它成员、后期维护的同事、新员工)花费更多的力气去理解代码。
代码往往被写一遍,被读何止十遍?特别是长生命周期的项目,代码提交到代码库后,一位作者,几十位读者,如果每位都多花几分钟去理解代码,那么总体上效率的损失是可观的。 损失还不止于读者,如果某位作者由于赶开发进度,写了一个魔鬼数字301来表示一个错误码,可以预见在未来的一两年里,会有若干同事来请教作者,301到底是什么意思?在什么场景下出现 ? 对于代码的作者同样会在后期浪费相当的时间,所以还不如多花两分钟定义一个漂亮的常量。
我们需要注意的破坏代码可读性的常见风格有:
1. 变量名称没有意义
2. 函数名称没有体现其功能,要读完函数才能了解其功能
3. 函数名称与其实现功能不一致,误导函数用户
4. 没有相关注释
5. 注释与实际代码不符
6. 魔术数字
7. 函数中太多的入参
。。。
当然除了这些字面上影响易读性的风格外,还有如:if语句中过多的判断条件、圈复杂度、函数太长等等,不一而足,这些都是需要我们避免的,虽然不影响功能,但是会影响自己和队友的效率。我们往往喜欢给自己贴上团队精神的标签,在软件开发团队里,代码的可读就是团队精神最好的诠释。当我们写下每一行代码时,都要想到,我会给队友造成困惑吗? 是不是加点注释会更好? 是不是起一个易懂的变量名? 相信良好的代码可读性会让作者和读者都有好心情和高效率,让我们的工作更加轻松而有效。
代码往往被写一遍,被读何止十遍?特别是长生命周期的项目,代码提交到代码库后,一位作者,几十位读者,如果每位都多花几分钟去理解代码,那么总体上效率的损失是可观的。 损失还不止于读者,如果某位作者由于赶开发进度,写了一个魔鬼数字301来表示一个错误码,可以预见在未来的一两年里,会有若干同事来请教作者,301到底是什么意思?在什么场景下出现 ? 对于代码的作者同样会在后期浪费相当的时间,所以还不如多花两分钟定义一个漂亮的常量。
我们需要注意的破坏代码可读性的常见风格有:
1. 变量名称没有意义
2. 函数名称没有体现其功能,要读完函数才能了解其功能
3. 函数名称与其实现功能不一致,误导函数用户
4. 没有相关注释
5. 注释与实际代码不符
6. 魔术数字
7. 函数中太多的入参
。。。
当然除了这些字面上影响易读性的风格外,还有如:if语句中过多的判断条件、圈复杂度、函数太长等等,不一而足,这些都是需要我们避免的,虽然不影响功能,但是会影响自己和队友的效率。我们往往喜欢给自己贴上团队精神的标签,在软件开发团队里,代码的可读就是团队精神最好的诠释。当我们写下每一行代码时,都要想到,我会给队友造成困惑吗? 是不是加点注释会更好? 是不是起一个易懂的变量名? 相信良好的代码可读性会让作者和读者都有好心情和高效率,让我们的工作更加轻松而有效。
相关文章推荐
- 谈防御式编程---发表于公司黑板报的第一篇文章
- VS2013MFC单文档工程学习笔记一 - 新建MFC单文档项目
- KETTLE使用javascript步骤过滤特殊字符
- Logging with Log4net (二)
- Spark大数据处理 之 RDD粗粒度转换的威力
- 线段树的实现
- 切换到MarkDown编辑器
- 基础的 Docker 容器网络命令
- 基础的 Docker 容器网络命令
- SQLServer触发器中 如何访问mySQL数据库?
- CSDN的技术问题
- ACM选修(动态规划)
- eclipse中编写代码时如何自动提示变量名?
- 职业经理人常犯的11种错误-余世维
- K smallest in array with detail explanation
- 变量和参数
- 分布式事务会面临的问题
- linux .run文件安装
- springmvc:Failed to convert value of type
- 黑马程序员——java基础-面向对象(三)