iOS - Xcode 自动生成注释文档
介绍
自动生成注释文档有三种方式:
docxygen
docxygen 感觉是这 3 个工具中支持语言最多的,可以配置的地方也比较多。我大概看了一下文档,觉得还是比较复杂,而且默认生成的风格与苹果的风格不一致。就去看后面 2 个工具的介绍了。另外,它虽然是开源软件,但是没有将源码放到 github 上让我感觉这个工具的开发活跃度是不是不够。
headerdoc
headerdoc 是 xcode 自带的文档生成工具。在安装完 xcode 后,就可以用命令行:headdoc2html + 源文件名 来生成对应的文档。我个人试用了一下,还是比较方便的,不过headerdoc的注释生成规则比较特别,只生成以 /*! */ 的格式的注释。还有一个缺点是每个类文件对应一个注释文件,没有汇总的文件,这点感觉有点不爽。
appledoc
appledoc 是在 stackoverflow 上被大家推荐的一个注释工具。比起以上两个工具,他的优点有:
它默认生成的文档风格和苹果的官方文档是一致的,而 doxygen 需要另外配置。
appledoc 就是用 objective-c 生成的,必要的时候调试和改动也比较方便。
可以生成 docset,并且集成到 xcode 中。这一点是很赞的,相当于在源码中按住 option 再单击就可以调出相应方法的帮助。
appledoc 源码在 github 上,而 doxygen 在 svn 上。我个人比较偏激地认为比较活跃的开源项目都应该在 github 上。
相对于 headerdoc,它没有特殊的注释要求,可以用/** / 的格式,也可以兼容/! */的格式的注释,并且生成的注释有汇总页面。
appledoc 的安装
那么简单介绍一下如何安装 appledoc,安装非常简单,只需要 2 步:
1 | git clone git://github.com/tomaz/appledoc.git |
当出现 INSTALL SUCCEEDED 时说明成功了,你也可以用 appledoc –version 查看验证下。如果可以正常执行下面指令则证明安装成功,否则需要查看报错说明。
1 | # 查看版本号 |
使用
1、使用终端进入代码目录
直接拖拽我们的工程文件夹到终端,然后按回车键
或者使用 cd+”项目名字目录”,然后按回车键
以上两种方法都可以进入到我们的工程根目录
2、指令用法及参数说明
1 | # 参考指令写法1(不生成docset文件) |
参数说明
参数 | 说明 |
---|---|
–no-create-docset | (选填参数)只生成html,不生成docset文件。如果需要生成,则去掉该参数即可 |
–output | (必填参数)生成结果输出路径,如“./doc”,会在工程目录下创建一个doc文件夹存放生成的文档。当然你可以指定一个完整的目录路径存放生成的文档 |
–project-name | (必填参数)工程名字,如“QQ” |
–project-company | (必填参数)公司名字,如“Tencent Inc.” |
–company-id | (选填参数)公司ID,如“com.tencent.QQ”,会生成文件名为companyID.projectName.docset的docset文件。如果不设置,则文件名为com.companyname.projectname.projectName.docset |
–docset-install-path | (选填参数)生成docset文件的目录。如果此目录不设置,默认会在~/Library/Developer/Shared/Documentation/DocSets/目录生成 |
/Users/superdanny/Desktop/QQ-Project/QQ/Views | 扫描对应路径下的类,如果想扫描当前目录所有文件,则将此路径换成.即可 |
如果是生成 docset 文件,则 --output
参数对应的目录会生成一个 docset-installed.txt 文件,里面记录 docset 存放的目录。
如果是不生成 docset 文件,则 --output
参数对应的目录会生成html文件。直接打开 index.html 文件即可查看。
-
2019-07-17
-
2019-05-11
项目最后的交接工作,我被派到了中移动总部进行封闭开发,暂时作为 iOS 方面的项目管理和推进,就之前来说,这个礼拜我负责的内容多了一些,除了我本身的代码维护以外,对外要处理项目的交接工作,对内要分配测试人员测试出的 bug,和一些缺失内容,优化内容的推进。一个礼拜下来,有一些收获。
之前看知乎上一个问题,是有什么是当上管理层才会想的事?虽然我还没有到那个地步,但是管理项目给我的一些体验让我觉得似乎可以把握到一些管理层的想法,比如很多时候我们觉得领导只看结果不问过程有点不可理喻,但是从另一方面来看这其实只是因为需要对接的内容太多,不问过程只看结果,可以最大程度的排除其他因素的干扰。另一个是就是个人的主观动能性,这阵子做项目管理的时候,我总是会因为分配下去的任务而收到关于很多任务的疑问,比如新增一项需求的时候,开发人员会询问关于这个功能在不同场景下需要表现成怎样,在一些无法实现的地方又应该怎样规避。在管理角度看,这些当然是合理的,但提问的时机太零碎了,容易被分散注意力,另一个是有些场景虽然没有给出标准,但其实可以横向参考其他类似的功能来实现需求,这时候提问并不是必要的,所缺乏的只是一点主动去思考,或者说是虽然想到了第一步,即会产生这个问题,但可能是某种局限导致开发人员没有往下一步怎么解决这个问题,我之前也存在过类似问题。切成开发人员角度,规避这些问题,一个是整理问题,统一解决,另一个是解决问题的方法,虽然可以思考怎么解决,但是如果解决方法最终没有通过产品的审核,那之前针对问题的解决也都白费劲,所以最好的应对方法是,发现问题,可以附上一条或两条解决方案,一并提交。我想这些经验对于以后我做个人开发或者管理都会有帮助。
这个礼拜接触到的新技术是使用 OC/Swift 自动生成文档的轮子: