最近有朋友在公众号后台给我留言，“Jerry啊，你最近写的都是一些SAP研究院里面用到的新技术，能不能写点SAP传统的开发技术比如ABAP相关的东西”？
其实Jerry在刚开始写这个公众号的时候，是写过很多ABAP的技术文章：
因为Jerry最近的工作，需要使用ABAP编程的场景不多，所以近期这方面的文章少了点。
在Jerry之前的文章 写在Github被微软收购之际 - Github的那些另类用法 曾经提到，SAP在Github上也有很多开源项目：
截至到今天(2019年7月26日)，已经有399个仓库了。
Jerry年初去成都天府软件园一家SAP partners公司拜访时，这家公司的技术主管曾经问过我，有没有推荐的ABAP编程规范。Jerry当时想了想，回答说，虽然SAP研究院内部确有严格清晰写成文档，多达七八十页的ABAP编程规则，但Jerry不确定这些编程规则是否能直接发给非SAP员工。
今天Jerry觉得这个问题我已经有完美的答案了：我们来聊聊上述SAP开源的Github仓库其中之一，包含了SAP官方推荐的ABAP编程规范：
https://github.com/SAP/styleguides
cheat-sheet文件夹里主要包含了CleanABAPCheatSheet和CleanABAPTheGoldenRules两个文件，前者包含了SAP认为要写出Clean的ABAP代码，需要遵循的准则和尽量避免的误区。
而CleanABAPTheGoldenRules这个文件，包含的就是SAP推荐的关于ABAP编程方方面面的最佳准则：
而Sub-sections文件夹里包含了一些话题的深入阐述：
这些话题每一个都值得用一篇文章展开聊，Jerry先挖个坑在这里，有机会再填：
Avoid Encodings
SAP这个github文件给出的推荐是，建议在给方法实现里的变量名取名时，避免使用前缀。下图红色高亮的代码是推荐的做法，而黑色的代码是应该避免的代码。
这很有趣，因为Jerry在SAP内部做ABAP开发，遵循的原则恰恰就是第二种做法。
作者也深知这个建议和SAP官网help.sap.com上定义的ABAP编程规范里变量命名规范有相矛盾的地方，但还是坚持认为变量名不要前缀，是更加符合现代编程规范的做法，并且让变量有更好的可读性。
Jerry的个人意见是，对于SAP partners的开发团队来说，不必纠结到底应该遵循help.sap.com上的变量命名规范，还是应该按照本文介绍的SAP github上介绍的规范来——更重要的是，整个团队内部达成一致，选择一套坚决执行。
Enumerations.md
在ABAP里使用枚举类型的几种方式：
Exceptions
ABAP异常处理的最佳实践。
Function Groups vs. Classes
给了为什么坚决推荐不再使用function group / function module，而是鼓励大家投入到面向对象编程怀抱的原因。
Modern ABAP Language Elements
搜集了一些现代的ABAP语法和ABAP关键字的用法。
Upper vs. Lower Case
ABAP 语言的大小写规范，经常会让很多刚刚从其他编程语言转过来的程序员觉得摸不着头脑，Jerry当年刚刚从C++编程转到ABAP编程也是如此。
这个子话题给出了推荐的大小写使用场景。
因为Jerry的日常工作几乎不会用到ABAP，所以我也没有时间就这些话题深入展开，大家可以好好利用这个Github仓库，让自己的团队都能开发一套clean的ABAP代码出来，感谢阅读。
更多阅读