Tag: 代码审核

代码审核之限制参数范围

这两天又看到一个历史遗留下来写得很糟糕的代码. 这个代码大概是求两条线的夹角. 发现这代码是因为有一个单元测试不通过, DEBUG进来 发现是因为 Acos 函数在输入参数大于 1的时候返回 Nan, 浮点运算有误差返回了类似 1.00000012 之类的大于1但是却很靠近1的数值. 比如JS里: 最后面的解决方法是: Math.acos(Math.max(Math.min(1, x), -1)); 通过这种方法把参数强制规定在-1到1期间. 但是这样的代码并不优美. 如果精度要求更严格, 可以自定义一个数值类型的类, 分开用整数来保存整数部分和小数部分, 这样需要定义加减乘除的运算, 但是由于整数部分参加运算没有精度损失, 所以不会有这样的问题. 不过得小心处理像进位这样的问题. 通过这种方法把参数强制规定在-1到1期间. 但是这样的代码并不优美. 如果精度要求更严格, …

代码审核之 重新造轮子

今天在看代码修改记录的时候发现有这么一处改动, 虽然这个改动已经很久了,但是我觉得有必要拿出来大家讨论一下: 2007年 .NET 3.5 之后推出LINQ,其实整个函数只是在做一件事,就是返回类成员 layoutList 中是 LayoutDevice (后面改成LayoutAnt )的列表.但实际上这通过 C#的LINQ只需要用 OfType<LayOutDevice> 或者 OfType<LayOutAnt> 即可(暂且不说改动包括重构类型) 左边的版本实际上是OK的,这就是学校的标教科书版本,无可厚非,但右边的这个版本就大有问题,因为参数含有引用 ref, 也就是说每次都把外面传进的变量给清空了,这种函数拿来单元测试并不友好. 如果一定要重新造轮子,两个版本都有小问题,一个是 private 方法不好单元测试,另一个是都使用了成员变量 layoutList, 最好是改成 public static 公有静态方法,传入 layoutList, 然后像第一种方式返回新的List.这样的话,这个公有静态方法就是不会更改 …

[坑爹的代码] – 变量未使用

工作中代码审核是非常重要的, 我觉得有时候分享这些坑是件很有意义的事情. 有一次, 有一个PR(代码提交)被2个工程师成功审核了, 但是之后发现那个PR带了一些不该带的改动,结果就是那两个评审被惩罚带些吃的(甜甜圈)给大家分享. 每次你都很小心, 生怕把功能给改错了(即使有少量的单元测试,但是你还是不放心), 后来你发现,这代码绝B是个坑,浪费了你大好的时间,结果这变量声明了根本就没有用到.. 很奇怪的是, 像 Resharper这样的代码质量工具竟然没有把无用的代码给标灰… 英文: – Value Not Used 本文一共 195 个汉字, 你数一下对不对. – 变量未使用. (AMP 移动加速版本) 赞赏我的几个理由. ¥ 打赏支持 扫描二维码,分享本文到微信朋友圈

git 和代码审核

我们团队 已经从 SVN 转到 git 代码管理 已经有一个多月了. 变化很大. 我最喜欢的就是 git 的 分布式仓库管理 和 Visual Studio Online 的代码审核. 分布式代码仓库 SVN是中央代码管理仓库. 意味着如果服务器挂了 开发人员就无法工作了. 但是GIT不同. GIT是多级分布式仓库. 所有的代码得先提交到本地仓库然后再 推送到远程仓库. 离线了一样可以工作. 并且 在 git …

再谈代码审核的重要性

一种观点是 写更多的代码 程序员就更有经验 这样程序里错误就会相对少一些. 但这并不是 说代码越多越好. 如果能用更少的代码完成更多的事 那么越少的代码隐藏的错误就更少. 统计代码行数只会鼓励糟糕的代码. Less is more! 代码审核 可以由多种方式来完成 比如可以结对编程 (Pair Programming) 或者可以由专门代码仓库负责人 按阶段审核并接受提交. 有了代码审核以下的错误就会少了很多. 英文: https://helloacm.com/case-study-importance-of-code-review/ 本文一共 171 个汉字, 你数一下对不对. 再谈代码审核的重要性. (AMP 移动加速版本) …

代码审核

再NB的程序员也有可能写出很垃圾的代码,特别是没睡醒的情况下.所以代码审核就显得尤其的重要. 当一个开发项目即将完工或者一个BUG修复时,尽管已经通过了测试,但是还是需要有一些人专门针对上传的代码进行审核 (Review). 有些代码是一般不会造成问题, 但是却有可能会效率低下,比如: 很有意思,有一同事写了这样的代码,其实本意是想把一个角度限制在 0 到 360 度之间,但是是浮点角度,也许他认为不知道怎么对浮点数取余,所以就这样设计代码,不停的减,不停的加360度, 至到在范围内. 且不说这样做的效率,浮点数不断多次的运算会造成误差.如果这个角度极大或极小,则这两个循环则非常的费时.这是有可能测试人员无法测出来的,不经过代码审核是不会发现问题的. C#里是支持浮点取余的(不过得注意符号,负数的取余也是负数), 即使不支持,也可以通过: double fmod(double a, double b) { return a - b * (int)(a / b); } …