使用描述性名称

使用可以传达事物内容和含义的名称。

CONSTANTS max_wait_time_in_seconds TYPE i ...
DATA customizing_entries TYPE STANDARD TABLE ...
METHODS read_user_preferences ...
CLASS /clean/user_preference_reader ...

不要只把注意力放在数据类型和技术编码上。它们对理解代码几乎没什么贡献。

" anti-pattern
CONSTANTS sysubrc_04 TYPE sysubrc ...
DATA iso3166tab TYPE STANDARD TABLE ...
METHODS read_t005 ...
CLASS /dirty/t005_reader ...

不要试图通过注释来弥补坏的名称。

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Use Intention-Revealing Names。

首选解决方案域和问题域术语

在解决方案域（即计算机科学术语，如 "queue" 或 "tree"）和问题域（即业务领域术语，如 "account" 或 "ledger"）中搜索好的名称。

按问题域命名时，业务层的命名最好听。对于采用域驱动设计而设计的组件（如 API 和业务对象）尤为如此。

按解决方案域命名时，提供大多数技术功能（如工厂类和抽象算法）层的命名最好听。

在任何情况下都不要试图加进自己的语言。需能够在开发人员、产品负责人、合作伙伴和客户之间交换信息，因此要选择所有人不用查定制词典就能理解的名称。

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Use Solution Domain Names and [...]: > Use Problem Domain Names。

使用复数形式

在 SAP 有一种传统习惯，那就是用单数形式命名事物的表，例如，country 表示“国家表”。外界普遍倾向于使用复数形式表示事物的列表。因此，建议最好改用 countries。

这条建议主要针对诸如变量和属性等事物。> 对于开发对象，可能存在同样> 也有意义的模式，例如，有一种广泛使用的规范，> 以单数形式命名数据库表（“透明表”）。

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Use Intention-Revealing Names。

使用能读出来的名称

关于对象会有很多思考和讨论，因此要使用能读出来的名称，例如，detection_object_types 优于诸如 dobjt 这种晦涩的名称。

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Use Pronounceable Names。

避免缩写

如果有足够空间，那就完整地写出名称。仅当超过长度限制时才使用缩写。

如果不得不缩写，首先考虑_不重要_的词。

采用缩写，可能第一眼看起来很高效，但很快就会变得含糊不清。例如，cust 中的 "cust" 究竟是指 "customizing"、"customer" 还是 "custom"？三者在 SAP 应用程序中都很常见。

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Make Meaningful Distinctions。

在各处使用相同缩写

人们会搜索关键字来查找相关代码。为此，应对相同事物使用相同缩写。例如，始终将 "detection object type" 缩写为 "dobjt"，而不是混合使用 "dot"、"dotype"、"detobjtype" 等等。

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Use Searchable Names。

用名词表示类而用动词表示方法

使用名词或名词词组命名类、接口和对象：

CLASS /clean/account
CLASS /clean/user_preferences
INTERFACE /clean/customizing_reader

使用动词或动词词组命名方法：

METHODS withdraw
METHODS add_message
METHODS read_entries

用诸如 is_ 和 has_ 之类的动词作为布尔方法的开头，读起来会很流畅：

IF is_empty( table ).

建议也像方法一样给函数命名：

FUNCTION /clean/read_alerts

避免干扰词，如 "data"、"info"、"object"

省略干扰词

account  " instead of account_data
alert    " instead of alert_object

或将其替换为某些确实更有价值的特定字眼

user_preferences          " instead of user_info
response_time_in_seconds  " instead of response_time_variable

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Make Meaningful Distinctions

每个概念选取一个词

METHODS read_this.
METHODS read_that.
METHODS read_those.

为一个概念选择一个术语并坚持使用；不要混合使用其他同义词。同义词会使读者浪费时间查找本不存在的差异。

" anti-pattern
METHODS read_this.
METHODS retrieve_that.
METHODS query_those.

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Pick One Word per Concept

仅在本意如此时使用模式名称

不要对类和接口使用软件设计模式的名称，除非本意真的如此。例如，不要将类称为 file_factory，除非它的确实施了工厂设计模式。最常见的模式包括：singleton、factory、facade、composite、decorator、iterator、observer 和 strategy。

更多信息参阅 [Robert C. Martin 所著的 Clean Code] 中的 Chapter 2: Meaningful Names: Avoid Disinformation

避免编码，特别是匈牙利表示法和前缀

鼓励丢掉_所有_编码前缀。

METHOD add_two_numbers.
  result = a + b.
ENDMETHOD.

而不是毫无必要地加长

METHOD add_two_numbers.
  rv_result = iv_a + iv_b.
ENDMETHOD.

Avoid Encodings > 深入介绍了这样做的理由。

命名规范

通用前缀

通用前缀是标识代码用途的重要手段，通常在项目中会以项目名作为一种通用的前缀；在SAP系统中也是类似的，例如使用FI，MM等模块作为通用前缀。

SAP前缀举例：FI_xxx
项目前缀举例：ABC_xxx

通用前缀在下文将使用<general prefix>或<prefix>表示。

注：对于客户定制的代码，对象的命名空间为Y或Z。

类的命名

全局类（Global Class）

Name	Class
`CL_<prefix>_`	Standard Class
`CF_<prefix>_`	Factory Class
`CX_<prefix>_`	Exception Class
`IF_<prefix>_`	Interface
`TC_<prefix>_`	Global Test Class
`TD_<prefix>_`	Global Test Double
`TH_<prefix>_`	Global Test Helper Class

局部类（Local Class）

Name	Class
`LCL_`	General local class
`LTC_`	ABAPUnit: Test class
`LTD_`	ABAPUnit: Test Double
`LTH_`	ABAPUnit: Helper Class

方法命名（Methods）

属性命名和变量命名

开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 15 天，点击查看活动详情

ABAP 整洁之道之命名规范