长期以来, SAP 提供的标准 ABAP 开发工具是我们对代码进行检查的唯一方式. 这意味着我们只能对 ABAP 服务器上的 ABAP 代码做出分析, 而离线代码则成为了纯粹的文本, 开发者无法对其进行检查. abaplint 的出现改变了这一点, 它可以在一定程度上 "理解" 代码, 帮助我们解决一些问题, 和 SAP 的标准工具形成有效的互补. 本文会介绍 ABAP 开发相关的工具 abaplint 以及它在开发过程中的应用.
本文链接: https://www.cnblogs.com/hhelibeb/p/12166288.html
原创内容, 转载请注明
基本介绍
lint 或 linter 是一种静态分析工具, 可以分析并标记代码中的错误, bug, 可疑结构. abaplint 是 ABAP 语言的 linter, 它基于 typescript, 可以在多种平台工作, 作者是 Lars Hvam(同时也是 https://github.com/larshp/abapGit 的作者).
项目地址: https://github.com/abaplint/abaplint
和 Code Inspector 等其它静态分析工具类似, abaplint 可以做到帮助我们找到有问题的代码, 确保统一的代码风格等事情.
应用
在编辑器中的应用
以 Visual Studio Code 中的 abaplint 插件为例, 它可以分析出代码中的错误, 如下图, abaplint 找出了短短一段代码中的 10 个问题.
鼠标划过报错内容时, 编辑器也会给出具体提示, 如下图,(上面的黑色主题的提示框边界不是很明显, 为了让读者看清楚提示框, 这里主题颜色使用了 Solarized Light)
在持续集成 (CI) 中的应用
在编辑器中使用 abaplint 对代码进行实时检查是一种典型的应用方式, 还有一种应用方式是通过 abaplint 对代码进行自动检查, 它可以是持续集成中的一个场景.
比如, 如果以 GitHub 作为代码托管平台, 可以安装 GitHub 的 abaplint 应用( https://github.com/apps/abaplint ), 配置需要检查的 repo 后, 每当对相应的 repo 发起 pr 或 push, 都会有自动的代码检查, GitHub 也会显示检查结果.(类似 SAP 系统中的传输前检查 CTS_REQUEST_CHECK)
下图是我的配置,
进行一次 commit 之后, 可以看到 abaplint 给出了 26 处问题和问题所在的代码位置.
此外, 也可以使用 Travis CI 或 GitLab 的 CI 来执行 abaplint 的自动检查. 具体可以参考该文:《Automatic checking of your ABAP code in GitHub/GitLab with CI and abaplint》
应用范围
abaplint 支持多种代码编辑器和代码托管平台, 列表如下,
- VS Code (source https://github.com/abaplint/vscode-abaplint )
- GitHub App https://github.com/apps/abaplint
- GitHub Actions https://github.com/abaplint/actions-abaplint
- GitLab Pipelines https://gitlab.com/sbu-absw/abaplint-example
- Bitbucket Pipelines https://bitbucket.org/larshp/abaplint_pipeline
- Azure Pipelines https://github.com/abaplint/azure-devops-example
- Travis CI
- Atom https://atom.io/packages/linter-abaplint (待实现, source https://github.com/larshp/linter-abaplint )
Code Climate Engine, 待实现
ABAP in Eclipse, (待实现, source https://github.com/abaplint/abaplint-eclipse )
配置
abaplint 支持很多检查规则(并且在持续地更新中), 可以通过 abaplint.JSON 文件来控制各个检查规则的启用与关闭, 设置某些具体的检查参数.
abaplint-clean-code 项目中包含了这些规则的介绍, 和配置文件示例. 第一次使用 abaplint 的用户可以以该项目中的配置文件示例作为模板, 按照自己的需要, 结合规则介绍进行修改.
关于规则介绍部分, 它不仅给出了规则的效果, 也参考 sap 的 style guides 给出了规则存在的具体原因.
以其中一个设置为例,
- "method_length": {
- "statements": 25,
- "ignoreTestClasses": false,
- "errorWhenEmpty": true,
- "reason": "https://github.com/SAP/styleguides/blob/master/clean-abap/CleanABAP.md#keep-methods-small"
- },
method_length 是方法长度的配置项; statements 的数量决定了方法的最大行数; ignoreTestClasses, 忽略测试类,
errorWhenEmpty, 对不含代码的空方法报错; reason, 该设置的原因.
(个人认为 25 有点小, 有时候容易导致浅模块)
相关网站
abaplint 项目下还有一些实用网站, 这里介绍几个我了解的.
http://playground.abaplint.org/
一个在线编辑器, 包含一个可编辑的 report 程序和一个可编辑的配置文件 abaplint.JSON, 可以通过它试验 abaplint 的效果.
https://syntax.abaplint.org/
一个 ABAP 的语法树网站, 十分强大. 如下图,
包含 ABAP 中的所有语句, 表达式和结构.
https://stats.abaplint.org/
对一些开源项目 https://dotabap.org/ 的统计, 包含项目的对象数量, 文件数量, 语句数量, 方法长度, 语句兼容性, 对象类型, 行数趋势等信息的统计. 可以帮助开源开发者分析自己的项目. 效果如下图:
abaplint 的意义
abaplint 目前的流行度似乎还不是很高(当前有 62 star, 24 fork, 在 abap 标签下分别排名第 8 和第 10). 但我相信它是一个很有意义 ABAP 开源项目, 未来可能会对 ABAP 的生态产生深远影响.
ABAP 开发者一直以来都在 SAP ABAP 服务器上进行开发工作, 代码的分析, 测试完全在 ABAP 服务器上进行. 复杂而笨重的 SAP 系统不是到处都有的, 而且这些系统大多是孤立的. 这意味着, 开发内容的分享十分不方便. 虽然理论上可以通过 SAP 系统工具对开发对象进行导入导出, 代码分析等工作, 但在本质上, 它们通常是为了一个组织内部的分享而存在的. 当一个素不相识的人在 GitHub 发布了一个新的开源项目时, 其它人无法得知这个项目曾经在 ABAP 服务器上进行过怎样的检查, 这会影响信任的构建. abaplint 独立实现了原本只能在 ABAP 服务器上进行的检查, 如果一个项目的每次 commit 包含 abaplint 的检查结果, 每个方法都有完整的单元测试, 那么人们对这个项目的信心将大大增加. 信心的增加会促使人们将更多资源投入到开源项目中, 从而促进社区的成长.
来源: https://www.cnblogs.com/hhelibeb/p/12166288.html