代码整洁之道
ABAP 整洁之道
世界级编程大师Robert C.
Martin著有《代码整洁之道》一书。这本书提出了一种观念：代码质量与其整洁度成正比。那么，为什么代码的整洁如此重要呢？下面分享一个小故事。
20世纪80年代末，有家公司写了个很流行的应用软件，许多专业人士都买来用。然后，发布周期开始拉长。缺陷总是不能修复。装载时间越来越久，崩溃也越来越频繁。不久之后这个公司就关门大吉了。多年后有位记者采访了这家公司的早期雇员，询问当时发生了什么事情导致公司倒闭。原来，当时他们赶着推出产品，代码写得乱七八糟。特性越加越多，代码也越来越烂，最后再也没法管理这些代码了。是糟糕的代码毁了这家公司。或许对于我们来说可能不会遇到这么严重的情况，但我们也要尽自己最大努力，编写整洁规范的代码。
作为一个ABAP开发人员，自然也要遵守某些规约，这里我想推荐的是CleanABAP这本开发指南。下面举一些例子来让大家更好地了解CleanABAP。
1\.
名称的定义:当我们在定义一个perform的时候，如果这个perform主要做的是对某张数据库表的检索，也许我们会定义成select_t001..或者read_t001..等等，但是CleanABAP并不推荐这种命名方式，CleanABAP更推荐的是使用可以传达事物内容和含义的名称来代替技术型编码，例如read_user_preferences..在传统sap中关于名称的定义，我们往往会用单数形式来进行命名，比如country，但是在CleanABAP中更推荐我们使用复数形式，因为外界普遍倾向于使用复数形式表示事物。
2\.
注释的添加:我们平时在编码的时候会添加很多的注释，以便于自己的理解，又或者是便于后续运维人员对于程序的理解。但是CleanABAP并不推荐这样。尤其是应避免用注释来掩盖不好的名称。“注释绝非坏名称的借口”写出整洁的代码并非要求我们禁止写注释，而是我们应该想出更好的替代方法，因为只有当想不出好的替代方法时才使用注释。
3.内联声明优于最前声明:在我们传统的abap开发中，我们会习惯于将变量的声明置于方法开头，下边用到的地方再进行赋值。但是CleanABAP推荐我们在变量首次出现的地方进行内联式的声明。例如:
METHOD do_something.DATA(name) = 'something'.
DATA(reader) = /clean/reader=>get_instance_for( name ).
result = reader->read_it( ).
ENDMETHOD.优于
METHOD do_something.DATA:name TYPE seoclsname,
reader TYPE REF TO /dirty/reader.
name = 'something'.
reader = /dirty/reader=>get_instance_for( name ).
result = reader->read_it( ).
ENDMETHOD.但是内联声明也并不通用于所有情况，在判断语句中我们就应避免。虽然在判断语句中进行内联声明程序可以正常执行(因为 ABAP
会像声明位于方法开头那样来处理内联式声明)，但是当方法体较长导致维护人员没发现内联声明的话，会令维护人员产生困惑。这种情况我们不应使用内联式声明而将声明放在最前面。
4\. 使用【`】
定义文字:传统abap开发中，我们会使用单引号来定义文字，但是CleanABAP并不推荐用单引号，而是用【`】(ESC下方的那个键)来定义字符串。原因是用单引号定义字符串会造成多余的类型转换。
以上就是关于CleanABAP所举的一些例子，虽然参照CleanABAP的规范我们可以编写出相对整洁的代码，但是这可能会导致性能方面的相对下降。因为没有两全法，既能整洁代码又能提高效率。但是CleanABAP在谈及性能方面时提到如果是为高性能组件编码，则应谨慎采纳本指南中的建议。如果不是，我们还是应尽量按照CleanABAP的规范来编写代码。
以下是CleanABAP的链接：
styleguides/CleanABAP_zh.md at main · SAP/styleguides · GitHub
作者：吴子超
审核：郑 浩
编辑：王 锐
