大多数情况下,人的记忆总是那么不靠谱。
项目中,时常修改了一处测试代码,结果版本发布后才发现那段该死的代码没有替换掉。比如测试支付时,越过中间若干判定价格逻辑,最后在发起支付处直接将价格写死为0.01¥方便测试,如下图
今天基于已有工程框架,开发新的app。有一些工程配置和目录结构可以复用,且像app初始化要做的事、检查更新、数据持久化模块大部分流程都是一样的,命名也大体相同。问题在于,此类代码有关联以前工程的业务层,部分业务类的定义在工程早期搭建阶段无法确定,而之后再加这类已经写好并测试无问题的组件初始化代码又容易遗漏,那么这时候最方便的莫过于注释+编译警告了。
所以问题来了,从上个项目起,代码全部使用Swift编写。以前Objective-C代码里使用#warning可以生成编译警告,但Swift里没有这种功能。Google了下,找到了一个编译时Perl脚本。最后经过简单修改,添加脚本如下:
TAGS="#TODO:|#FIXME:|#WARNING:"
ERRORTAG="#ERROR:"
find "${SRCROOT}" \( -name "*.h" -or -name "*.m" -or -name "*.swift" \) -print0 | xargs -0 egrep --with-filename --line-number --only-matching "($TAGS).*\$|($ERRORTAG).*\$" | perl -p -e "s/($TAGS)/ warning: \$1/" | perl -p -e "s/($ERRORTAG)/ error: \$1/"
其原理就是检查".h"、".m"、".swift"后缀的文件中,每一行代码是否包含给定特征字符串。匹配两种字符串,一种是以TAGS中定义过的值开头,中间包含任意数量的字符,直到行尾,匹配到即报黄色警告;另一种是以ERRORTAG中定义过的值开头,中间包含任意数量的字符,直到行尾,匹配到即报红色错误警告。
需要说明的是,第二种虽然报编译错误,但并不影响编译生成二进制文件,调试很方便。效果如下图:
接着,在编译过程中和正在使用的代码产生了命名冲突。如下图:
百度地图定义的错误类型被匹配到了 百度地图定义的错误类型被匹配到了起初打算在定义标签前增加#符号,但发现每次敲字多打个#开头非常不顺畅。像上图中的误报情况,毕竟是少数,把百度地图错误处理代码稍加修改便可(Error和:之间加个空格)。如下图:
修改标记误报后的百度地图错误处理代码
网友评论