如何用工具检查 ABAP 代码是否符合 Clean ABAP 编码规范

本文在 ABAP 系统里的操作截图，来自 SAP 社区博客，地址如下：

• https://community.sap.com/t5/application-development-blog-posts/how-to-enable-clean-code-checks-for-abap/ba-p/13544856

• https://community.sap.com/t5/technology-blogs-by-sap/clean-code-checks-for-abap-cloud-edition/ba-p/13562780

笔者之前的文章，介绍了 Clean ABAP 的概念。

聊聊 Clean ABAP

简单的说，Clean ABAP 由四个“一”组成：一个由 SAP 主推的开源项目，一套通用的 Clean ABAP 编程规范，一套匹配该规范的代码扫描工具，加上一套对应的代码自动重构工具。

图中紫色的椭圆区域，包含的就是 Clean ABAP 编程规范，在笔者之前的文章有详细介绍：

SAP 官方 ABAP 编程规范（2023 版）

本文介绍下图粉色椭圆区域的内容：Code pal for ABAP，一个开源的 ABAP 代码扫描工具。

该工具基于 Clean ABAP 编码规范对 ABAP 代码进行扫描。

当然，工具不可能 100% 覆盖编码规范中定义的所有规则，因此图中 Code pal for ABAP 所占的区域，只是 Clean ABAP 编码规范的一个子集。

pal 在英语中有朋友，老兄，兄弟的意思。

Code pal for ABAP 是开源工具，Github 地址如下。

使用 abapGit 将其源代码克隆到本地 ABAP 系统。

笔者之前的文章已经介绍过 abapGit 的使用：

使用 abapGit 在 ABAP On-Premises 系统和 SAP 云平台 ABAP 环境之间进行代码传输

从官网上将 abapGit 的完整源代码，拷贝到 ABAP 系统里新建的报表里，激活即可使用。

新建一个 Online Repository：

输入 Code pal for ABAP 的 Github 地址，点击 Create Online Repo：

点击 Pull，即可把远端 Github 网站的 ABAP 代码，全部拉取到本地 ABAP 系统里，自动生成对应的 ABAP 类和其他开发资源。

激活这些 ABAP 开发资源之后，使用事务码 SCI 进入 ABAP Code Inspector，开启 Code pal for ABAP 的扫描选项：

选中所有 Test Category 为 code pal for ABAP 的检查规则：

新建一个 Check Variant，包含刚才开启的检查规则：

单击每个 Checks 的 Attributes 按钮，可以对违反这个检查规则的 ABAP 代码的处理行为，进行自定义。

比如对于输入参数类型为布尔类型这条检查规则，可以定义违反规则后抛出消息的严重级别，以及是否允许通过 ABAP Pragma #EC BOOL_PARAM(一种特殊的注释) 来屏蔽掉。

配置完毕之后，就能在 ABAP Development Tool 的 ATC 工具里使用了：

选择刚才创建的包含了 Code pal for ABAP 检查的 Check Variant 即可：

完成代码扫描之后，选中每条检查结果，可以看到详细的错误说明和解决方案提示。

在 SAP BTP ABAP 云端编程环境里，可以使用 Code pal for ABAP 的云版本。

在 ABAP Development Tool 里打开 abapGit 仓库的视图：

把 Code pal for ABAP 对应的云端版本克隆下来即可：

https://github.com/SAP/code-pal-for-abap-cloud

之后就能够看到对应的检查规则了。后续的使用方法，同 ABAP Opportunities 环境里一致。

Code pal for ABAP 里的很多检查选项，能够给我们提供一些有意思的思考。

每个选项在 Github 上都有一个对应的文档，介绍了引入这个检查选项的初衷和背景，以及一些讨论。

比如一个方法的输入参数，选择布尔数据类型，有什么好处和弊端？

其对应的文档链接如下：

https://github.com/SAP/code-pal-for-abap/blob/master/docs/checks/boolean-input-parameter.md

为什么 Clean ABAP 编程规范里，不推荐在方法设计时，使用布尔类型的输入参数呢？

因为编程规范认为，这种设计有违反设计领域里单一职责 - Single Responsibility 的嫌疑。

比如下面这个方法：

METHODS update
  IMPORTING
    do_save TYPE abap_bool.

在 update 的实现体内，完成的逻辑是：如果传入的输入参数值为 abap_false, 那么只修改内表值，不进行 commit 操作。反之，调用另一个 Update Function Module 执行数据库层面的修改。

表面上看，用一个方法，处理了两种业务场景，节省了代码量。

但是 Clean ABAP 编程规范认为，这样的设计增加了 update 方法的测试复杂度，同时也降低了消费 update 方法的代码的可读性。

消费 update 方法的应用代码：

do_save(abap_false).
do_save(abap_true).

上面这种消费代码方式，并不是自描述的。

接手这段代码的维护人员，可能看了之后一头雾水：这里的 abap_true 和 abap_false, 是用来区分 save 操作是同步或者异步？是真实提交或者 simulation 即模拟方式提交？是保存时考虑或者忽略权限检查？

总之在阅读 do_save 方法实现源代码之前，维护人员只能瞎猜。

Clean ABAP 编程规范的建议就是：简单的将 do_save 拆分成两个方法：

METHODS update_without_saving.
METHODS update_and_commit.

虽然看起来可能有点笨拙，但提高了代码的可测试性和可读性。

总之，Clean ABAP 编码规范和其配套的工具，不但能从规则和技术上，确保 ABAP 代码符合 Clean 规范，而且通过阅读编码规范的文档，也能从中学到很多编码的最佳实践和准则。