关于 ABAP 变量命名的前缀，到底要还是不要？

有从事 ABAP 开发的朋友问我，业界约定俗成的 ABAP 变量命名前缀，到底在 SAP 官方什么文档里能够查到？

比如下边这些前缀命名规范：

• 局部变量前面加上 l_
• Importing 参数前面加上 i_
• Exporting 参数前面加上 e_
• Changing 参数前面加上 c_
• Returning 参数前面加上 r_

在网上什么地方能够查到？

答案当然是 SAP Help 网站了。

左侧展开 ABAP Programming Guideline, 按照路径 Structure and Styles，Naming，Program-Internal Names，就可以在右侧找到这些前缀了。

文档提到，Procedures(包含 Subroutine 和类)的接口参数，出于清晰识别之目的，应该使用这些前缀。

文档接下来讨论了是否应该将变量的数据类型，也作为命名前缀的一部分进行声明。
看着这大块的英文段落是否觉得头大？我试着简单翻译一下。

在实际编程开发中，通常会为变量的命名制定规范，包括可能的前缀和后缀。在 ABAP 里前缀的使用普及程度远远高于后缀，但这些命名规范常常会陷入过于形式化的严格要求中。

通过这种命名规则创建的变量名称，往往包含冗余信息，难以维护，而且通常无法在可读性和自解释代码二者间达到完美的平衡。

因此，我们应该将精力集中在最为关键且通用的一小部分变量命名领域的讨论上。进一步的规范，在不同的开发团队或组织内部进行讨论才更有实际意义。

如果使用前缀/后缀，通常的做法是将对象的技术属性包含在这些前缀/后缀中。

一般来说，不建议在变量名称中明确指出技术信息。

此外在 ABAP 中，技术属性种类繁多，无法通过简单的短前缀或后缀来全面涵盖这些种类。不同的技术附加信息也具有大量的组合，以下是一些例子：

对于 ABAP data type 或者 data type，有些从业人员建议用前缀 v 代表 value，c 代表 constant.

同理，s 代表 structure，t 代表内表，sv 代表静态变量，那么 st 呢？代表静态内表，还是 sorted table？随着前缀需要描述的技术属性越来越复杂，引起阅读者混淆和费解的可能性也随之增加。

关于数据对象的作用范围或上下文，命名约定通常要求使用 g_ 和 l_ 作为全局和局部数据对象名称的前缀。

g_ 作为全局数据对象的前缀，固然是唯一确实必要的约定，然而将所有非全局对象都标记为 l_ 以表示局部作用域通常是不必要的。只有当局部名称与更全局的名称相同，并且相应地缺少区分标识符会导致代码难以阅读时，才需要使用 l_.

对于方法参数，我们建议使用 i_、e_、c_ 和 r_ 作为 importing、exporting、changing 和 returning 参数的前缀，以便与方法内声明的数据对象区分开来。

除此之外，没必要再通过额外的前缀来表达技术信息。

尤其是在方法参数中，前缀中的技术信息往往会导致混淆，而不是提高可读性。例如，前缀 is_ 既可能表示 importing structure，又可能表示 is_XXX 的判断语义，比如 is_released, is_confirmed 这种状态符号位。

如果无法从参数的描述性名称和其所在的方法名称中明确了解该参数的作用，那么这些参数本身的命名就存在问题，或是方法本身没有清晰的定义。这种概念层面的问题，无法通过技术前缀来解决。

总之，我们建议谨慎使用包含技术信息的命名前缀。

当然，每个组织可以根据实际开发需要，自由使用这些命名规范。

在 ABAP 环境中，由于类型多样性、上下文的复杂性以及按引用和按值传递的不同，制定一套完整、自成体系、一致且技术上正确的前缀和后缀规则并非易事。目前业界已有的通用版本，往往只是约定俗成，且这些约定通常不完整，也不总是适用于所有的 ABAP 开发项目。

以上就是 SAP 官方帮助文档里，对变量命令前缀的一些建议。

或许是在帮助文档里打下的伏笔，在笔者之前文章介绍的 Clean ABAP Code 里，对这个话题的建议是，不要使用任何前缀。

Clean ABAP 对于这个建议的链接如下。

Clean ABAP 认为，像下面这种参数变量加了前缀的方式，是一种画蛇添足式的实践：

METHOD add_two_numbers.
  rv_result = iv_a + iv_b.
ENDMETHOD.

推荐做法是将所有的前缀全部去掉：

METHOD add_two_numbers.
  result = a + b.
ENDMETHOD.

Clean ABAP 给出的理由是：

这种前缀是编程开发洪荒时期的遗留物，在那个遥远的时代，当时代码需要被打印出来并在纸上阅读，因此引入这些前缀，可以避免开发人员为了查找某个变量的类型，而在纸上翻来覆去。

现代开发环境可以轻松访问变量的数据类型、签名和对象导航信息，根本不再需要这些前缀来辅助。
https://github.com/SAP/styleguides/blob/main/clean-abap/sub-sections/AvoidEncodings.md

Clean ABAP 旗帜鲜明的反对变量命名前缀，除了上述理由外，还给出了以下大论据：

1. ABAP 变量长度为 30 个字符限制，不值得浪费 3 到 4 个额外的字符作为前缀。

2. ABAP 代码里的常量，是否以 sc_ 或 cv_ 开头，并不会真正影响可读性。

3. 无法将变量最常用的五个维度（kind, direction, scope, type, mutability）压缩到通常不超过两个字符的前缀。这些前缀只会导致毫无意义的冲突，带来阅读者理解上的混淆。

4. 对于字面上相同的前缀，不同的团队可能有不同的内部规范。比如 lr_ 到底是指对象引用还是 range table?

5. 前缀可能会产生歧义。团队 A 可能将变量 id_business_partner 解读成 importing data for business partner, 团队 B 可能解读成存储 business partner 的 id 属性。

6. 前缀会带来不必要的重构工作量。假设将变量的数据类型，作为变量前缀的一部分。则调整变量数据类型后，需要同步调整其变量名称的前缀。

7. 目前主流的编程语言，比如 Java，JavaScript，TypeScript，Python 等等，完全不使用前缀，也丝毫不影响其代码可读性。

我们可以查看 SAP 早期标准程序的代码，能观察到中规中矩的变量前缀用法：

越到后期，这些前缀在标准程序里的痕迹就越少了：

这种趋势，也呼应了 Clean ABAP Code 里提到的一句话：

We think that avoiding prefixes is the more modern and readable variant and that the guideline should be adjusted.

翻译成中文就是：避免前缀是更现代、可读性更好的做法。传统的 ABAP 编程规范，也到了该对应做出调整的时候了。

https://github.com/SAP/styleguides/blob/main/clean-abap/sub-sections/AvoidEncodings.md

笔者的个人意见是，变量命名前缀的取舍，还得项目团队成员们根据实际情况，在团队内达成一致。

如果是负责已有项目的维护，且项目中的存量代码，都是按照传统命名前缀的方式来书写的，那么盲目照搬 Clean ABAP Code 抛弃前缀的建议，可能效果会适得其反。