整洁代码之道-命名约定

在SAP中造成命名混乱的是遗留代码。几十年来，它基本上没有被触动过，也没有被重构过，现在它只是一个任你吃的自助餐厅。你可以在那里找到一切，从旧代码，注释代码行，多种语言注释，1000+行函数等等。

我不想说根本没有约定。但在所有 SAP 开发中，一致性是稀缺的。一旦我们都知道是变量的前缀。命名为工作区（或结构）或经典前缀 LT（本地表），GS（全局结构）的 WA_XXX，当面向对象出现时，LO / GO（本地/全局对象）是一个有趣的规则，在 ABAP 编程中是独一无二的。

过去和现在都存在一些限制，这使得坚持每个人都乐于遵守的某个小规则列表变得不那么容易。例如，许多实践都是基于数据字典和SAP对象的创建方式派生的。例如，结构字段受字符限制。类的名称，相同的故事。此规则适用于整个 SAP 环境。我们没有 JavaScript 的奢侈来写 256 个字符的长名字。我们所拥有的事实是，所有这些对象最初都是用德语创建的，因此许多缩写在英语中没有任何意义。举个例子：VTWEG - Vertriebsweg，KUNAG - Kunde Auftraggeber，VKORG - Verkaufsorganisation …我会在休眠的斯塔西特工认为我在召唤他们之前停在这里。

另一点值得一提，导致这种混乱的是，每家公司都试图定义自己的一套规则和指导方针。SAP没有为每个人提供清晰简洁的规则。没有更高的权威。我很感激在过去几年中，他们开始发布指南并更多地参与这个主题。但在此之前，它是狂野的西部。对于我参与的每个项目，我都能看到一个规则。没有规则的规则。没有明确的共识。

首先什么是命名约定？

可能这应该是开始的第一点。但你已经知道了，我觉得先抱怨更令人耳目一新:D

命名约定是一组规则，由行业中的开发人员就如何使其代码更具可读性达成一致。或者我应该放弃“在一个行业”。如今，有如此多的编程语言，它使人们从一种语言迁移到另一种语言的生活成为人间地狱。我们应该意识到，来自不同编程语言的开发人员需要快速适应新编程语言的读写代码。

啊，就是这样。应该仅此而已。但是你看，这为辩论或…髞。我所说的强加，是指关于如何编写代码的无休止的教导。

对 SAP 的一些想法

干净的代码和清晰的命名约定意味着没有惊喜。对于第一次坐在别人代码前的程序员来说，正常的一天应该是：“是的，是的。啊哈。啊！是的。这很酷“等等。不是经典的“那是什么？LST_BZIRK_T什么意思？

当我们用 ABAP 编写代码时，我们已经从一些缺点开始了。变量不区分大小写，漂亮的画家（代码格式化程序）允许您只有大写或小写的代码。您可以告别驼峰命名案例（尽管在 CDS 视图中这是有效的）。唯一可行的选择，或多或少已经应用，是蛇案（使用下划线）。

让我们谈谈 SAP 中的日常对象以及如何改进它们。

数据字典对象

我知道物体的长度存在巨大问题。例如，字段名称的长度不能超过 30 个字符，或者数据库表名称只能包含 15 个字符。通常这就足够了，但如果不是，请使用缩写。拜托，不是发明的。只需谷歌正确的缩写。

名称应明确数据库将包含的内容或字段表示的内容。SAP 已经通过 S/4 HANA 推动了新趋势。将来，我们甚至不需要手动创建自定义字典对象。CBO 和 CDS 观点将成为常态。CDS 视图的趋势已经是使用完整的单词字段名称，以便我们最终可以像 5 个字符的名称一样抛弃 COBOL。

Reports / Functions / Performs

作为建议（不仅来自我，也来自SAP），尽量不要使用它们。它们迟早会过时。我已经参与过不允许创建新项目的项目。

类

在命名空间之后，使用 CL、IF 或 CX。类的名称应该是一个名词，并描述它维护的对象。如果可能，尽量不要使用缩写。我们将主要保留这些类的类型。例如，实用程序类以 UTIL 结尾，服务类以 SRV 结尾。

对于属性，约定是从 M 开始它们，然后按属性的类型（表、结构、标志、变量…

方法应该描述一个动作，正在发生的事情。它通常包含一个动词（或应始终包含一个动词）。GET 和 SET 方法访问私有成员属性，而 READ 应仅用于从数据库层中选择数据。如果某个方法返回布尔值，则以 IS/ARE 启动该方法

IF is_flight_scheduled( iv_connid = iv_connid 
                        iv_carrid = iv_carrid 
                        iv_fldate = sy-date 
                      ).
"Create new flight 
ENDIF.

包

在自定义项目中，我喜欢有一个清晰的层次结构并相应地构建我的对象。我喜欢从超级包 ZSP 开始，它包含基于每个开发区域（例如，ZMP_SD 或 ZMP_MM ）的多个主包 ZMP。每个主包都包含自己的开发包 ZDP，具体取决于开发的功能类型（ UI，数据代理，API 等）

Others …

变量/常量前缀（如LT_、GS_、MV_C_）是您总是会偶然发现的东西。大多数 ABAP 程序员都将其嵌入到他们的编码方式中，即我们的“条件反射”。我们将有一个可怕的时刻来改变这一点。虽然我喜欢使用明确命名的变量的想法（例如，使用items 而不是 ls_item ）。

注释

在一个写得很好的应用程序中，注释甚至不应该存在。注释表示代码中的内容不清楚。不过，我知道，在现实世界中，逻辑可能会变得非常复杂，需要一些额外的解释。

注释时，请使用有用的信息。不要陈述显而易见的事情，不要添加其他语言的评论，不要发表“有趣”的评论。是的，这很有趣，直到它不再有趣。然后就是杂乱和烦恼。

例如，不要像下面那样写。