编写更好 ABAP 代码的原则

避免深层嵌套

不要编写深度嵌套的循环、case 和其他控制结构。而不是使用 if、检查和返回来嵌套控制结构的退出。

不好的习惯：

ABAP 复制代码

LOOP AT lt_data ASSIGNING <ls_data>.
  IF a = b.
    IF c = d.
      IF ls_data IS NOT INITIAL.
        ls_data-field = 'aaa'.
      ENDIF.
    ELSE.
      ls_data-field = 'bbb'.
    ENDIF.
  ELSE.
    ls_data-field = 'ccc'.
  ENDIF.
ENDLOOP.

好的例子：

ABAP 复制代码

LOOP AT lt_data ASSIGNING <ls_data>.
  IF a <> b.
    ls_data-field = 'ccc'.
    CONTINUE.
  ENDIF.

  IF c <> d.
    ls_data-field = 'bbb'.
    CONTINUE.
  ENDIF.

  CHECK ls_data IS NOT INITIAL.
  ls_data-field = 'aaa'.
ENDLOOP.

嵌套深度

嵌套深度是由于使用控制结构（分支、循环）而嵌套的语句块的数量。我们将讨论存储过程（方法）层次上的嵌套深度。在其他层面上不得进行实现。

ABAP 编译器将最大嵌套深度限制为 256。
将例程（方法）内的最大嵌套深度限制为五层。

除了可执行语句的数量之外，过程（方法）的控制结构对于其清晰度和可追溯性也很重要。每个嵌套级别的嵌套分支和循环（IF、CASE、DO、WHILE、LOOP 语句等）变得不太清晰且更难以跟踪。因此，必须将嵌套深度限制在过程内，例如通过将函数移动到其他例程中。

使用更现代 ABAP 语句可以帮助限制最大嵌套深度，例如：

-如果语句或预定义函数替换整个控制结构（例如，使用 ALL OCCURRENCES 附加语法进行 REPLACE ，用这种方式可以取代循环

使用数字极值函数 nmax( ) 和 nmin( ) 来确定最大值或最小值，这种可以取代 IF 控制结构。

参考链接：

Nesting Depth

使用自动代码检查

使用语法检查、扩展程序检查和代码检查器来验证代码语法、架构、准则、漏洞和其他质量方面。

推荐一个开源的检查工具 abapOpenChecks ：Open Source list of checks for SCI/ATC

安装方式

打开 abapGit：

先下载 .zip 文件，然后在 abapGit 种选择 New Offline，进行离线加载，接着填好仓库名，和本地包，点击创建：

然后点击 Import：

接着就会出现很多代码，我们点击 Pull 按钮：

安装需要一定的时间，安装完激活就会得到如下的界面：

删除旧的和未使用的代码

未被使用的代码是永远不会执行的程序部分，因为它们不再被需要或在任何时候实际上从未被需要。这些代码可以在程序的开发（拒绝原型）或维护（切换到新代码而不删除旧代码）过程中积累。

虽然旧代码不会直接影响执行的程序部分，但它仍然对产品产生负面影响。在程序执行期间无法访问的程序部分不会提供任何好处。相反，它们会导致程序生命周期过程中的成本增加，因为必须将它们识别为未用于维护和进一步开发目的。最坏的情况是，如果这些程序部分没有立即被识别为未使用，它们将在进一步的开发或重构措施中被重用或修改。对未使用的代码进行更改会浪费大量时间和精力。此外，这些程序部分增加了程序执行期间程序缓冲区中所需的空间。

这部分代码还会干扰使用 ABAP 单元的模块测试或使用 eCATT 的场景测试实现最大测试覆盖率的目标。实时系统中未使用的代码要么经过测试，这非常耗时，要么没有经过测试，这导致测试覆盖率很差。因此，必须尽快识别并删除未使用和不可访问的程序部分。

语法检查和扩展程序检查将帮助您找到它。

语法检查会警告您有关本地类未使用的私有方法的信息。
扩展程序检查会警告您有关控制结构中永远无法访问的未使用声明或语句块。

参考帮助：SAP Help

不要忽视任何程序错误

对错误做出及时反应。它可以是一条正确的消息，也可以是博客条目，也可以是异常引发。但不要忽视它们，否则，你将无法找到任何问题的原因。

SAP帮助

ABAP 错误分类

ABAP 提供了以下概念，程序可以使用这些概念对不同的错误情况做出正确的反应：

Exceptions 异常

异常是 ABAP 程序执行过程中的事件，当程序无法以有意义的方式继续运行时，这些事件会中断程序。异常由 ABAP 运行时环境或程序中的 ABAP 语句 (RAISE EXCEPTION) 引发。异常处理使您能够对这些事件做出反应。未处理的异常会导致运行时错误；也就是说，程序终止并输出描述异常的简短转储。

Assertions 断言

断言在程序中制定了必须满足的条件，以确保程序正确继续。断言由 ASSERT 语句定义。

Messages 消息

消息是最多可以包含四个用于值替换的占位符的文本，并且可以使用 MESSAGE 语句显示或以其他方式发送。

这三个概念要么涉及程序或用户对错误情况的处理（异常或错误消息），要么导致受控程序终止（断言或退出消息）。

针对不同错误的处理方式

异常情况适用于用户无法控制的所有意外情况。例如，其中包括过程调用期间无效的参数值或不可用的外部资源（例如文件）。
断言用于检测需要立即终止程序的不一致的程序状态。
消息仅用作经典 dynpro 处理范围内的错误对话框的对话框消息（如果仍然可用）。如果您想在程序不适合继续运行的情况下实现程序终止，请从现在开始使用断言而不是终止或退出消息。

MESSAGE 语句不仅用于在经典 dynpro 中显示对话框消息，而且还可以部署为以受控方式终止程序或在 MESSAGE ... RAISING 变体中引发经典异常（如果选择了适当的消息类型）。这会邀请您结合不同的概念，这可能会导致问题。这可以追溯到仅由经典 dynpro 驱动的旧编程模型，其中错误情况直接需要向用户输出消息。

对于考虑关注点分离（SoC）的现代编程来说，在发生错误时是否向用户发送消息的问题通常只能在更高的软件层中回答。因此，发生这种错误情况的层必须首先对异常做出反应，这又代表了更高层的新情况，它可以对对话消息或任何其他错误消息做出反应。