企业官网建设流程全解析

模块化基础：子程序与Include程序（5篇）

第4篇：避坑指南：子程序与Include程序的常见误用场景解析

模块化是好习惯，但“过度”或“错误”的模块化比没有模块化更可怕。一个子程序只做一件事——这是好的；把一行代码也封装成子程序——这是过度设计。Include程序能共享代码——这是好的；但循环包含、全局变量污染会导致程序崩溃——这是灾难。本文汇总子程序和Include程序开发中最常见的8个误用场景，每个都配有故障案例、原因分析和解决方案，帮你避开模块化入门的90%常见问题。

一、子程序过度拆分：当“模块化”变成“碎片化”

1.1 故障案例

某开发者在报表中创建了50多个子程序，每个子程序只有寥寥数行，甚至有些子程序只调用另一个子程序。

PERFORM init_workarea. PERFORM get_input. PERFORM validate_date. PERFORM validate_material. PERFORM validate_vendor. " 每个校验一个子程序 PERFORM call_db. PERFORM process_header. PERFORM process_item. ...

问题：

• 主流程长达30行PERFORM调用，想要理解实际逻辑必须在多个子程序间来回跳转。
• 大量参数传递，增加了代码量。
• 修改一个校验逻辑需要打开多个子程序。

1.2 原因分析

• 误解了“模块化”的目的：模块化是为了降低复杂度和提高可维护性，而不是追求子程序数量最小化或最大化。
• 过度遵循“一个子程序只做一件事”，把“一件事”定义得太细。

1.3 解决方案

合并逻辑相关的子程序。例如，多个字段校验可以合并为一个validate_input子程序，内部依次校验。

FORM validate_input USING iv_date TYPE d iv_matnr TYPE matnr iv_lifnr TYPE lifnr RETURNING VALUE(rv_valid) TYPE abap_bool. " 日期校验 IF iv_date IS INITIAL OR iv_date < sy-datum. rv_valid = abap_false. RETURN. ENDIF. " 物料校验 SELECT SINGLE matnr FROM mara INTO @DATA(lv_matnr) WHERE matnr = iv_matnr. IF sy-subrc <> 0. rv_valid = abap_false. RETURN. ENDIF. " 供应商校验 ... ENDIF.

经验法则：一个子程序应该至少在20-50行之间，或者承担一个完整的逻辑步骤（如“校验输入”、“从数据库加载数据”、“生成输出”）。如果子程序少于5行，且仅被调用一次，考虑内联。

二、Include循环引用：程序无法激活的“死锁”

2.1 故障案例

开发者创建了两个Include程序：ZINCL_A和ZINCL_B。ZINCL_A中写了INCLUDE ZINCL_B，而ZINCL_B中写了INCLUDE ZINCL_A。当尝试激活其中任何一个时，系统报错：“Include recursion detected”。

2.2 原因分析

Include是文本包含。当编译器展开ZINCL_A时，遇到INCLUDE ZINCL_B，于是去展开ZINCL_B；在ZINCL_B中又遇到INCLUDE ZINCL_A，形成无限循环。SAP编译器会检测并阻止这种循环。

2.3 解决方案

• 禁止循环包含。检查所有Include文件的包含关系，确保依赖图是有向无环图（DAG）。
• 可以使用事务码WHERE USED LIST（SE80中右键点击Include → 使用位置列表）查看哪些程序包含了它，以及它包含了哪些其他Include。
• 重构：将公共内容提取到第三个Include中，然后让A和B都包含它，而不是相互包含。

三、全局变量污染：Include中的变量“泄漏”

3.1 故障案例

Include文件ZINCL_GLOBAL：

DATA: gv_counter TYPE i.

主程序A：

REPORT z_prog_a. INCLUDE zincl_global. START-OF-SELECTION. gv_counter = 10. PERFORM sub_in_b. WRITE gv_counter. " 期望10，实际可能被修改为20

主程序B中的子程序（也在某个Include中）：

FORM sub_in_b. gv_counter = 20. ENDFORM.

由于gv_counter是全局变量，任何子程序（即使来自不同Include）都可以修改它，导致程序行为难以预测。

3.2 原因分析

• Include中的变量声明会直接成为主程序的全局变量，没有访问控制。
• 当多个开发者在不同Include中命名了相同的全局变量时，会发生冲突。
• 子程序意外修改了全局变量，而调用方不知情。

3.3 解决方案

方案一：减少全局变量，改用参数传递

将Include中的DATA改为仅在子程序内部使用，或通过参数传递。

方案二：为全局变量加唯一前缀

如果必须使用全局变量，使用程序特定的前缀，如gv_<程序缩写>_<含义>。

方案三：使用类或函数模块

类提供了私有属性和方法，彻底隔离变量作用域。

最佳实践：Include文件中只包含常量定义（CONSTANTS）、类型定义（TYPES）和子程序（FORM），避免声明可修改的全局变量。

四、滥用Include代替子程序：逻辑难以追踪

4.1 故障案例

开发者将一个复杂的业务逻辑拆分成十几个Include文件，主程序变成了纯粹的“包含指令集”：

REPORT z_huge_program. INCLUDE zincl_init. INCLUDE zincl_calc1. INCLUDE zincl_calc2. INCLUDE zincl_calc3. INCLUDE zincl_output. INCLUDE zincl_cleanup.

当出现bug时，开发者需要在十几个文件之间来回切换，无法在一个视图中看到完整的业务流程。

4.2 原因分析

• 过度使用Include作为“逻辑分割”工具，而忘记Include的本质是跨程序复用。
• 对于仅在一个程序中使用的逻辑，使用子程序分割比Include更合适，因为子程序可以在同一个文件中，无需跳转。

4.3 解决方案

• 仅在需要跨程序复用时才使用Include。如果一段逻辑只在一个程序中使用，请使用子程序，并且将子程序放在同一个主程序文件中（最好在程序末尾）。
• 如果一个程序真的太大（超过5000行），可以按功能模块拆分为多个Include，但每个Include应该代表一个可独立理解的功能块（例如ZINCL_DB_ACCESS、ZINCL_ALV_OUTPUT），而不是随机分割。

五、忽略子程序的异常处理：程序静默失败

5.1 故障案例

子程序内部发生错误（如除零、空引用）但没有返回错误标志，调用方继续执行，导致后续数据错误。

FORM divide USING a b CHANGING result. result = a / b. " 当b=0时，程序直接崩溃，但调用方没做保护 ENDFORM. PERFORM divide USING 10 0 CHANGING lv_result. WRITE lv_result. " 这行永远不会执行

5.2 解决方案

在子程序开头校验输入，使用标志位返回错误。

FORM divide USING a b CHANGING result error. IF b = 0. error = abap_true. RETURN. ENDIF. error = abap_false. result = a / b. ENDFORM. PERFORM divide USING 10 0 CHANGING lv_result lv_error. IF lv_error = abap_true. MESSAGE '除数不能为零' TYPE 'E'. ENDIF.

或者使用RAISE异常（但FORM不支持，需改用函数模块）。

六、修改Include后忘记激活主程序

6.1 故障案例

修改了ZINCL_COMMON中的一个子程序逻辑，并激活了该Include。但主程序Z_MAIN没有被重新激活。运行时，Z_MAIN仍使用旧代码，导致行为异常。

6.2 原因分析

Include是在编译时嵌入主程序的。如果主程序没有重新编译（激活），它仍保留旧的Include内容。

6.3 解决方案

• 强制规范：修改任何Include后，必须手动激活所有引用它的主程序。
• 可以使用事务码SE38→ 菜单“实用程序” → “查找引用程序”来定位所有使用该Include的主程序。
• 在开发环境，可以通过编写一个自动扫描程序或使用ABAP Test Cockpit规则来提醒。

七、混淆子程序的作用域：意外修改全局变量

7.1 故障案例

子程序内部使用了一个与全局变量同名的局部变量，误以为是在操作全局变量。

DATA: gv_index TYPE i. FORM calc. DATA: gv_index TYPE i. " 局部变量，屏蔽了全局 gv_index = 10. ENDFORM. gv_index = 5. PERFORM calc. WRITE gv_index. " 输出5，不是10

7.2 解决方案

• 遵循命名规范：全局变量用gv_前缀，局部变量用lv_前缀，避免同名。
• 在子程序中不要声明与全局变量同名的变量。
• 如果需要修改全局变量，直接使用gv_index（不要重复定义）。

八、Include文件过大，影响编译性能

8.1 故障案例

一个Include文件包含了数百个子程序、数十个全局变量，长达8000行。任何包含它的主程序编译时都会非常缓慢，且激活时可能触发内存不足。

8.2 解决方案

• 将大型Include按功能拆分为多个小型Include（例如ZINCL_IO、ZINCL_CALC），每个主程序只包含需要的部分。
• 对于通用的核心库，考虑转换为函数组（Function Group）或类，它们有更好的封装和加载机制。

九、总结：误用场景速查表

模块化的目的是让代码更清晰、更易维护，而不是制造新的混乱。遵循上述最佳实践和避坑指南，你就能在子程序和Include的使用中游刃有余。

下一篇我们将通过一个完整的实战项目，演示如何用子程序+Include搭建一个可维护的小型项目框架。

📌下篇预告：《实战落地：用子程序+Include搭建一个可维护的小型项目框架》

作者：你的ABAP学习伙伴
版本记录：2026年5月

💬 你在模块化开发中还遇到过哪些“奇葩”误用？欢迎留言分享你的排坑经验。