ABAPCodeInspector是每个ABAP开发者工具箱中必备的代码检查工具之一。使用ABAPCodeInspector自带的标准检查项，可以帮助开发者快速发现ABAP代码中潜在的缺陷，提高代码质量，提高代码运行性能。本文分享作者在ABAP应用开发工作十余年中积累的一些使用ABAPCodeInspector的经验。在ABAPCodeInspector的CheckVariant中，我们可以根据自己的需要灵活选择对ABAP代码进行何种类型的扫描动作。下图是一个例子，意思是从SELECT语句中扫描TableNames，寻找ABAP代码中所有对数据库表具有读写权限的地方。扫描的具体行为可以点击蓝底白色感叹号图片获取帮助文档。下图例子中打勾的选项，意思是检查SE11的ABAP字段中的TechnicalSettings在访问的数据库表中是否正确维护，比如表的缓存类型是否设置正确。性能检查Select-Statement可以转换。X%offieldsused-查看内表字段使用率假设我们使用SELECT*从一个表中读取数据到ABAP内表，然后在后续代码字段中只使用A，读取的表共有SE11中的B字段，那么A除以B的结果越小，读内表字段的使用率越低。换句话说，您可能会考虑仅将SELECT*替换为SELECT真正需要的字段？您只需要在上述设置中保持一个最低阈值。CodeInspector在扫描代码时，一旦检测到使用率低于维护阈值就会报错。上图中的20表示20%。SearchDBOperationsinloopsinloopsacrossmodularizationunitsJerry2007年刚加入SAP开始学习ABAP编程时，前辈告诫我不要在LOOP中使用SELECT语句，这会极大影响代码性能.上图是CodeInspector扫描的例子。在doubleLOOP循环中，使用SELECT读取数据库表CRMD_DPP_HI_BLCK。NestedLoops-嵌套循环检测虽然应用代码中嵌套循环的数量并不多，但代码运行的绝对时间并不重要-但是写具有至少指数时间复杂度的代码在任何情况下都不是好的编程习惯。这个设置可以帮助我们快速找到所有的嵌套循环。复制LOOPAT的当前表行以找出所有LOOPAT...INTO位置。理论上这些地方可以用LOOPAT...REFERENCEINTO或者ASSIGNING代替。当内表的行结构字段较多时，使用后两种方式可以获得一定的性能提升。低性能。参数传输-检测所有使用“按值传递”的参数传输。对编程语言中参数传递的两种方式，引用传递和值传递的分析，至今仍是很多互联网公司的面试题之一。该选项允许您指定参数传递方式扫描哪种类型的参数：在ABAP中，理论上，参数传递采用引用传递方式，性能总是优于值传递。具体性能会提高多少取决于传递的具体参数类型，不能一概而论。安全检查–SELECT中的动态和特定于客户端的访问–动态SQL语句检测将扫描符合以下范例的动态SQL：动态表访问：SELECT*FROM(dbtab)WHERE…DynamicWHERE条件：SELECT*FROMdbtabWHERE(where_cond)对某些表的访问：SELECT*FROMdbtabWHERE...特定于客户端的访问：SELECT*FROMdbtabFROMWA...CLIENTSPECIFIED...该选项并不禁止您使用动态SQL语句-事实上，有有大量使用动态SQL语句的例子——但是提醒大家不要忘记SQL注入的预防措施：一旦扫描，如果有用户输入参与了这些动态SQL语句的拼接，那么不要忘记查看上下文是否使用CL_ABAP_DYN_PRG处理用户输入。在SORTEDTables中搜索APPEND和INSERT...INDEX会检测所有将APPEND操作应用于已排序内表的位置。拥有此扫描选项可以帮助您避免下图中第13行出现此类运行时错误。检查SY-SUBRCHanding-在调用ABAP关键字后检测系统变量sy-subrc返回一个值并执行适当的错误处理。在Jerry看来，错误检测和处理是每个程序员都应该具备的基本素质。对应ABAP，就是每次调用ABAP的关键字完成一个操作，都要检查sy-subrc的值，确认操作是否成功。当然，你也可以根据项目的实际情况，让CodeInspector只检查某些类型的ABAP关键字调用。比如上图的意思是调用READTABLE关键字后只检查sy-subrc是否已经检查过。MissingtablecontentcheckbeforecallingSELECT…FORALLENTRIESIN使用FORALLENTRIESIN前，必须先检查内表itab是否为空。此选项扫描未根据此规范编写的代码。ProgrammingConventions-Namingconventions在这个界面中，为ABAP中不同类型的变量设置你的团队约定的命名约定，然后CodeInspector可以扫描代码中所有违反这些命名约定的地方。MetricsandStatistics检查类别下的设置是一些非常有趣的统计数据。或者举个例子。下图中红色区域的设置，表示如果一个类的方法中的可执行语句行数超过150行，CodeInspector会报警告信息。这是为了防止大家写一个过于冗长的方法。蓝色区域的设置是如果每100行可执行代码对应的注释量少于10行就报警告信息。这些阈值可以根据实际情况修改或关闭。FAN-OUTStructuralMetrics-计算方法的扇出值在模块化编程的上下文中经常提到方法的扇入值和扇出值。这对概念在编程界并不是首创，而是起源于半导体行业逻辑电路设计：逻辑门的扇出系数定义了该门可以驱动的最大数字信号输入数，而扇出系数代码模块的out值表示直接在其下的模块数。该选项使您能够计算方法的扇出因子。扇出系数太小，意味着该方法基本不会调用其他更底层的函数。有两种可能：（1）方法本身的逻辑很简单，只有两三行代码，比如类的setter/getter方法；（2）这个方法的模块化没有做好，并且还有优化的空间。比如一些直接写在方法中的语句，可以细化为更底层的函数，在方法中调用。CommentLanguageMetrics此选项可以计算代码中出现的德语注释函数。还创建了OOSizeMetrics选项，以防止您无意中创建怪物类（monsterclass）：一旦您关心的类的属性超过设定的阈值，例如类的成员，类的公共/私有方法当焦点超过选项中设置的值时，CodeInspector会报警。ProgramComplexityTest-cyclomaticcomplexity-强大的代码圈复杂度（cyclomaticcomplexity）测试工具。这是另一个可以帮助您编写干净的ABAP代码的强大工具。代码的圈复杂度是多少？根据维基百科的定义，我们将一段代码的执行流程画成有向无环图，然后可以通过以下公式计算圈复杂度：https://en.wikipedia.org/wiki...圈复数度=图中的边数-图中的节点数+2这其实就是我们研究生课上学的欧拉定理《图论》。看下面的例子：上面8行ABAP代码，圈复杂度为3，如何计算呢？先画出它对应的有向无环图：这个图的边数为3，即图中黑红绿三条粗线。该图中的顶点数为2，如图中两个菱形的蓝色图例所示。最后，圈复杂度为3–2+2=3。统计表明，代码的高圈复杂度与高失败率之间存在很强的正相关关系。不难理解，代码的圈复杂度越高，意味着里面嵌套的IF-ELSE、SWITCH等逻辑越多，无论是代码的原开发者还是后来接手的维护人员，读起来会头晕。因此，您可以使用ABAPCodeInspector的扫描选项随时监控您的代码的圈复杂度。SearchDBOperations列出了您关心的代码中出现的所有SQL操作关键字。搜索ABAP语句模式选项也可用于根据您指定的正则表达式扫描ABAP代码。比如你想找出代码中所有出现READTABLEXXXWITHKEYX=X的地方，只需要在上面的输入框中填写对应的正则表达式即可，即用*代表任意字符串:READTABLE*WITHKEY*=*然后ABAPCodeInspector会根据我们预期的行为扫描代码：ABAPreportRS_ABAP_SOURCE_SCAN也可以实现完全相同的功能：总结ABAPCodeInspector是每个ABAP开发者工具箱中必备的代码检测工具工具之一。使用ABAPCodeInspector自带的标准检查项，可以帮助开发者快速发现ABAP代码中潜在的缺陷，提高代码质量，提高代码运行性能。本文分享作者多年使用ABAPCodeInspector的一些高级功能，以满足作者团队对交付的产品代码各个维度的质量检查、监控和报表输出功能。希望能对大家的ABAP项目开发有所帮助。.
