代码统计、分析工具

sunsmell 发布于2019-06-25 14:16 / 1983人阅读

摘要：分享两个工具代码统计代码分析关于第三方工具的安装，推荐使用，唐巧大神也在博客中推荐过。是专门用于代码统计的命令行工具，支持几乎所有语言。统计结果作为一个静态的代码分析工具，功能非常强大，而且出自国人之手。

分享两个工具

代码统计：CLOC

代码分析：oclint

关于第三方工具的安装，推荐使用Homebrew，唐巧大神也在博客中推荐过。使用brew search xxxx来查看是否有对应的工具可以使用Homebrew安装。

CLOC

CLOC是专门用于代码统计的命令行工具，支持几乎所有语言。

使用Homebrew安装：brew install cloc，使用也非常简单，命令行进入项目目录，执行cloc ./即可，这样会统计目录下的所有代码。如果不希望统计某些文件夹，可以设置需要忽略的目录，比如忽略Pods文件夹：cloc ./ --exclude-dir=Pods。

统计结果：

oclit

oclit作为一个静态的代码分析工具，功能非常强大，而且出自国人之手。

为了一劳永逸，首先安装xctool：brew install xctool，这是Facebook提供的代替苹果xcodebuild的工具。

安装oclit：brew install Caskroom/cask/oclint，为了能够在Xcode上直接显示代码分析的结果，还需要完成以下几步

添加Aggregate，

为刚才创建的Aggregate添加运行脚本，注意：不要在选中Aggregate的状态下点击Editor菜单，不然Add Run Script Build Phase按钮是灰色的

添加脚本代码，脚本代码和官方文档有些不同。

#import path
export PATH=${PATH}:/usr/local/bin
#import what we have in bash_profile
source ~/.bash_profile
#check for oclint
hash oclint &> /dev/null
if [ $? -eq 1 ]; then
echo >&2 "oclint not found, analyzing stopped"
exit 1
fi

hash xctool &> /dev/null
if [ $? -eq 1 ]; then
echo >&2 "xctool not found, analyzing stopped"
exit 1
fi

cd ${SRCROOT}
xctool -workspace MyProject.xcworkspace -scheme MyProject clean
xctool -workspace MyProject.xcworkspace -scheme MyProject -reporter json-compilation-database:compile_commands.json build
oclint-json-compilation-database 
-e Pods 
-- -rc=LONG_LINE=100 
-rc=NCSS_METHOD=60 
-rc=MINIMUM_CASES_IN_SWITCH=1 
| sed "s/(.*.m{1,2}:[0-9]*:[0-9]*:)/1 warning:/"

注意：上面代码中的MyProject需要替换成你的工程名，如果你的工程不是用workspace来管理的，那么其中这两行代码

xctool -workspace MyProject.xcworkspace -scheme MyProject clean
xctool -workspace MyProject.xcworkspace -scheme MyProject -reporter json-compilation-database:compile_commands.json build

需要替换为

xctool -project MyProject.xcodeproj -scheme MyProject clean
xctool -project MyProject.xcodeproj -scheme MyProject -reporter json-compilation-database:compile_commands.json build

4.编译刚才创建的Aggregate，需要耐性等待结果，完成之后就能看到oclint给出的结果

错误排查

若build成功了但是没有给出任何警告，很可能是出现了错误

检查
是否有警告，之前就遇到team没选择对，导致没有分析结果，或者像我一样选择None。

检查是否存在~目录下.bash_profile文件，因为此文件是隐藏文件，首先要让Finder能显示隐藏文件，命令行执行defaults write com.apple.finder AppleShowAllFiles TRUE 后 killall Finder，在Finder中Command+Shift+G前往文件夹，填写~查看，若无此文件，命令行进入次目录创建一个即可:cd ~后touch .bash_profile。恢复隐藏文件的隐藏defaults write com.apple.finder AppleShowAllFiles FALSE 后 killall Finder

分析结果

oclit的代码分析结果包括三种警告等级从高到底依次是：P1，P2，P3。

变量名长度：Long variable name P3 Variable name with 28 characters is longer than the threshold of 20 变量名超过20个字符，当然20的阀值是可以设置，之后会介绍。

反向逻辑：Inverted logic，比如

if (![response isKindOfClass:[NSError class]]) {
    //
}
else{
    //
}

方法行数：Long method P3 Method with 179 lines exceeds limit of 100，方法下的代码超过100行，不包括注释。

参数未使用：Unused method parameter P3 The parameter "section" is unused.，不过这个警告在IOS开发中比较普遍，可以忽略

嵌套深度Deep nested block P3 Block depth of 8 exceeds limit of 5，比如各种block的嵌套或者if/else的嵌套

当然还有很多其他的情况

圈复杂度(CCN)：High cyclomatic complexity P2 Cyclomatic Complexity Number 31 exceeds limit of 10，意味着代码的复杂程度

NPath 复杂度：/High npath complexity P2 NPath Complexity Number 384 exceeds limit of 200，具体不是很清楚

目前遇到的P2就是这些，P1的还没有遇到过。

回到刚才的脚本代码中

-- -rc=LONG_LINE=300 
-rc=NCSS_METHOD=60

这是oclit给出的参数设置LONG_LINE表示每行代码的最长字符数，NCSS_METHOD表示有效代码行的最大行数。0.8dev版本的其他参数包括

CYCLOMATIC_COMPLEXITY
Cyclomatic complexity of a method, default value is 10

LONG_CLASS
Number of lines for a C++ class or Objective-C interface, category, protocol, and implementation, default value is 1000

LONG_LINE
Number of characters for one line of code, default value is 100

LONG_METHOD
Number of lines for a method or function, default value is 50

MINIMUM_CASES_IN_SWITCH
Count of case statements in a switch statement, default value is 3

NPATH_COMPLEXITY
NPath complexity of a method, default value is 200

NCSS_METHOD
Number of non-commenting source statements of a method, default value is 30

NESTED_BLOCK_DEPTH
Depth of a block or compound statement, default value is 5

可惜的是，并没有Unused method parameter相关参数。

总之，oclint的分析还是具有比较高的参考性，对于提高代码的可读性、可维护性还是有一定帮助的。

服务器托管私有云统计工具分析网站统计分析工具数据分析统计工具数据统计分析工具

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/15650.html

代码测试覆盖率分析

摘要：背景最近我们前端团队在重构大量的组件，为了保证代码质量，我要求团队中的成员必须编写单元测试，并且测试覆盖率达到以上。总结对一个持续集成的项目来说，单元测试非常重要，同时最好具有较高的测试覆盖率。背景最近我们前端团队在重构大量的 UI 组件，为了保证代码质量，我要求团队中的成员必须编写单元测试，并且测试覆盖率达到 80% 以上。那么问题来了，为什么是 80% 的覆盖率？这是一个硬性...

kevin 2019-08-20 18:55 评论0 收藏0
关于写作那些事之终于还是无法忍受纯人工统计数据

摘要：背景作为正在探索如何写作并发表到各大博客平台的新人目前虽然已基本弄清写作和发表的基本流程但是离打造个人知名度还差很大很大一段距离尤其处于新手阶段需要的更是自信与外界的积极反馈看着各平台日益增长的阅读量和粉丝量心中自然不甚欣喜但是持续的技术输背景作为正在探索如何写作并发表到各大博客平台的新人,目前虽然已基本弄清写作和发表的基本流程,但是离打造个人知名度还差很大很大一段距离. 尤其处于...

wh469012917 2019-07-24 10:53 评论0 收藏0
ESLint 在中大型团队的应用实践

摘要：自动化接入和升级方案通过命令行工具提供一键接入升级能力，同时集成到团队脚手架中，大大降低了工程接入和维护的成本。原始代码经过解析器的解析，在管道中逐一经过所有规则的检查，最终检测出所有不符合规范的代码，并输出为报告。引言代码规范是软件开发领域经久不衰的话题，几乎所有工程师在开发过程中都会遇到，并或多或少会思考过这一问题。随着前端应用的大型化和复杂化，越来越多的前端工程师和团队开始重...

alogy 2019-08-26 10:34 评论0 收藏0
一文掌握 Linux 性能分析之网络篇（续）

摘要：这是性能分析系列的第五篇，前四篇在这里一文掌握性能分析之篇一文掌握性能分析之内存篇一文掌握性能分析之篇一文掌握性能分析之网络篇在上篇网络篇中，我们已经介绍了几个网络方向的性能分析工具，本文再补充几个。本文首发于我的公众号 CloudDeveloper(ID: cloud_dev)，专注于干货分享，号内有大量书籍和视频资源，后台回复「1024」即可领取，欢迎大家关注，二维码文末可以扫。...

chengjianhua 2019-08-08 13:46 评论0 收藏0
一文掌握 Linux 性能分析之网络篇（续）

摘要：这是性能分析系列的第五篇，前四篇在这里一文掌握性能分析之篇一文掌握性能分析之内存篇一文掌握性能分析之篇一文掌握性能分析之网络篇在上篇网络篇中，我们已经介绍了几个网络方向的性能分析工具，本文再补充几个。本文首发于我的公众号 CloudDeveloper(ID: cloud_dev)，专注于干货分享，号内有大量书籍和视频资源，后台回复「1024」即可领取，欢迎大家关注，二维码文末可以扫。...

zero 2019-06-28 11:19 评论0 收藏0