谈谈可读性在团队软件工程中的重要性--发表在公司黑板报的第二篇文章

尽管很多软件工程相关的书目、以及项目组平时的代码检视中都会提及代码可读的重要性,但在我们的实践中,代码可读依然没有得到足够的重视。可读性较差的代码会导致其读者(团队其它成员、后期维护的同事、新员工)花费更多的力气去理解代码。

代码往往被写一遍,被读何止十遍?特别是长生命周期的项目,代码提交到代码库后,一位作者,几十位读者,如果每位都多花几分钟去理解代码,那么总体上效率的损失是可观的。 损失还不止于读者,如果某位作者由于赶开发进度,写了一个魔鬼数字301来表示一个错误码,可以预见在未来的一两年里,会有若干同事来请教作者,301到底是什么意思?在什么场景下出现 ? 对于代码的作者同样会在后期浪费相当的时间,所以还不如多花两分钟定义一个漂亮的常量。

 

我们需要注意的破坏代码可读性的常见风格有:
1. 变量名称没有意义
2. 函数名称没有体现其功能,要读完函数才能了解其功能 
3. 函数名称与其实现功能不一致,误导函数用户 
4. 没有相关注释 
5. 注释与实际代码不符
6. 魔术数字
7. 函数中太多的入参

。。。

 

当然除了这些字面上影响易读性的风格外,还有如:if语句中过多的判断条件、圈复杂度、函数太长等等,不一而足,这些都是需要我们避免的,虽然不影响功能,但是会影响自己和队友的效率。我们往往喜欢给自己贴上团队精神的标签,在软件开发团队里,代码的可读就是团队精神最好的诠释。当我们写下每一行代码时,都要想到,我会给队友造成困惑吗? 是不是加点注释会更好? 是不是起一个易懂的变量名? 相信良好的代码可读性会让作者和读者都有好心情和高效率,让我们的工作更加轻松而有效。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值