多亏了"Clean ABAP"风格的指南，我对源代码的可维护性有了更多的思考。在这种情况下，一个特别重要的点是可读性。

在风格指南中，提出了许多提高可读性的建议。它是关于顺序和组合，数据支持，你应该在一行和多行中放置多少语句。还有一个建议是使用描述性的名字。

我觉得这个主题非常重要。遵循应用程序的想法可能很容易，也可能很难。与ABAP语法不同的是，变量、类和方法的名称在长度、允许的字符和允许的位置上"只"有限制。如何最终调用它们决定了开发人员。因此，许多名称和术语组合很快出现，必须在应用程序的整体上下文中理解它们。

下面是一个小示例，说明类名和方法名对可读性的影响。它是在"实验室条件"下设计的。这里有一些关键点：

技术上，可以用不同的方法来解决。例如，使用ABAP核心数据服务（CDS）和基于CDS的ALV，或使用SELECT语句在表上和"classic"ALV（面向对象或功能模块重用\u ALV\u GRID\u DISPLAY\u LVC）或混合。例如，我们在表VBAK和"classic"ALV上使用SELECT语句。

我们开发了一个名为ZCL\u LIST的类，其中包含两个名为SELECT和SHOW的方法。所有的源代码都是在这个类中实现的。

我该怎么说？类和方法的名称几乎没有揭示上下文的任何信息。

如何做得更好？根据样式指南，云服务器购买，建议从解决方案域或问题域中选择术语。在我们的示例中，业务术语增加了可读性。以下是一些如何找到它们的想法：

检查概念是否可用。那里使用的术语可以提供很好的线索。检查help.sap.com帮助.如果您确定了一个或多个属于您的开发的业务对象类型，请尝试事务BAPI。检查相关文档、功能模块和说明中使用的术语。通过事务处理或在线尝试SAPterm。如果您确定了一个或多个重要的表/数据类型，请查看英文文档。如果标识了重要的数据元素，请选中默认组件名称。用英语而不是母语登录。然后打开你从日常工作中了解到的商业交易并检查条款。

现在，我们可以从解决方案领域中选择不同的方法。我们开发了一个名为ZCL\u SALES\u ORDERS\u LIST的类，云服务器怎么用，它有两个方法，分别是SELECT\u SALES\u ORDERS和SHOW\u ALV.

这两个方法已经提供了更多的信息。同样可以想象的是从数据库中选择销售订单或从数据库中读取销售订单或读取销售订单。

第一种和第二种方法违反了"关注点分离（SoC）"的设计原则，因为我们的类ZCL销售订单列表有太多的任务，比如从数据库表中读取和显示数据。

对于一个小报告来说，这可能是可以的。但如果添加了新的需求/特性，我们很快就会创建一个不灵活的整体。以我的经验，这些要求产生得很快。特别是如果有效地使用列表来避免创建一个整体，我们可以使用三个类：

ZCL\u SALES\u ORDERS\u listZCL\销售\订单\提供商（或ZCL\销售\订单\阅读器）ZCL\u SALES\u ORDERS\u ALV

类ZCL\u SALES\u ORDERS\u LIST使用类ZCL\u SALES\u ORDERS\u PROVIDER选择销售订单，返现网，然后通过类ZCL\u SALES\u ORDERS\u ALV输出。有趣的是，使用专门的类还有一个优点，即类名变得更具表现力，从而有助于更好地理解。

如果我们以前有ZCL\u SALES\u ORDERS\u LIST->SELECT\u SALES\u ORDERS，我们现在可以避免在方法名中重复术语SALES\u ORDERS。所以我们得到了ZCL\u SALES\u ORDERS\u PROVIDER->SELECT.

如果我们在SELECT语句中使用JOIN加法来同时读取销售订单的标题和位置数据，我更希望使用SELECT这个名称。像选择标题和位置这样的方法当然也可以。

否则，在云上，建议使用诸如读取标题或读取位置之类的专门方法。也许加上了一个类似于\u DB.

好的，现在就到此为止-这些是关于类和方法名的一些想法。如前所述，有无数种方法。你觉得怎么样？