Introduction
Coming from a computer science background and having learnt ABAP on the job in a SAP consultancy, I always wondered why there are so restrictive naming-conventions and why every customer has their own custom ones, each apparently trying to trump the other with even more detailed naming-conventions for every little technical possibility... To me it seems to be a SAP-speciality that has vanished everywhere else (or so it seems ... hello cobol legacy applications, hello hungarian notation)
Having read this interesting uwe.schieferstein/blog/2009/08/31/nomen-est-omen--abap-naming-conventions a while ago and having to tackle a big custom code-base ourselves (with our own inevitable hardcore-detailed naming conventions and our own fair share of technical debt ...) we discussed what to focus on in the future.
Goals: Simple, short & concise code conventions that ease development and make the code easier to read.
After all, you as a developer are spending about 70% of your time reading & analysing existing code. You want that code to be short and readable. And you don't want to constantly lookup naming conventions, do you?
How much code do you fully understand from top to bottom? Can you analyse & memorize only 100 lines of unbroken, unknown code and estimate the implication of new changes? I don't. I feel big relief if that code is broken up into as many form-routines (functions, methods, whatever) as possible: We dearly want Seperation of Concerns.
Decisions
- No global variables (except where required... Hello, dynpro-binding): Local variables are the norm
- No technical duplication of information already explicitly & neatly specified in the type-system (we love statically typed languages and despise dynamic languages, dont' we?). Instead focus on semantics, readability and meaningful names.
- Keep it short: Form-Routines, Function-Modules and Class-Methods are limited to 70 lines of code/LOC.
From all we've heard this should automagically lead to better (not good) maintainability
Some Rules derived from these decisions:
- Since every variable is local there is no need for "My prefix hereby tells you that I am ...*fanfare*... local!".
So no more L_ prefix. If you see a variable like "flight_time", it is local. Spare prefixes for special occasions, to emphasize. - Global variables are a special case, use the G_ prefix to discriminate them as the despicable things they are.
Your brain/eye instantly catches these special prefixes, they no longer disappear between all those other L_ ... - Class-attributes are like local variables, they are class-local, they are not global.
As such they don't have any prefix either but you may choose to use "me->attribute" to clearly indicate attribute-access. - Use meaningful constants like co_open_in_external_window instead of 'E'
It does not matter whether these constants are defined globally or locally, just use a "CO_" prefix to specifiy them as being a constant.
If you have an interface that only contains constants (an ABAP design pattern to create nice container for constants), you may omit the "CO_" prefix altogether. And yes, you may argue this constant-prefix too :wink: - If you define types it does not matter whether the type-definition is local-only or globally, just use "TY_" for types.
- The most controversial: The variable shall have a meaningful name, no abbreviations and shall not contain technical information that is already specified in the type-system. Focus on the semantics!
So no more "ls_sflight" and "lt_sflight" but "sflight_entry" and e.g. "sflight_tab_delete" (emphasize on "delete" to describe what entries are contained in the table and why).
You may argue "So you traded lt_ for the _tab suffix and actually gained nothing, well done.".
In some way or the other you have to declare a table as being a multitude of things, it does not matter if you use the typical s-plural suffix for "sflightS" or use a "_tab" suffix, the important thing is to focus on its meaning and reserve prefixes to emphasize on important things (hello ugly globals...).
Besides, ABAP itself is already shouting in your face whether that variable is a table/structure:
READ TABLE x, LOOP AT x, x-comp = 'foobar' etc. you really don't need anything more 90% of the time... - Use mathematical notation instead of abbreviations that make the code harder to read: <= is way more intuitive than LE.
Just use normal math-operators that you've already learnt in school. I often hear that NE and LE are perfectly reasonable and understandable but this argument always comes from guys with decades of experience. I think the more simple way (not easy) is always to be preferred, there is no point to distinguish yourself from lesser experienced by using voodoo'ish notation...
TL/DR: This leads to the following inevitable naming-convention-matrix:
| Prefix | Comment |
|---|
| Locals | NONE | |
| Globals | G_ | |
| Field-Symbols | <NONE> | Really ugly: global Field-Symbols: <G_XXX> |
| Atttributes | NONE | Use "me->attribute" to distinguish from locals if necessary |
| | |
| Constants | CO_ | No distinction local vs. global (Omit prefix in constant-interfaces) |
| Types | TY_ | No distinction local vs. global |
| | |
| Form Using | I_ | Concentrate: Using = Importing/Input, no need to distinguish |
| Form Changing | C_ | |
| | |
| FM Importing | I_ | Try by reference |
| FM Exporting | E_ | Try by reference |
| FM Changing | C_ | Try to avoid |
| FM Table | T_ | Avoid! |
| | |
| Method Importing | I_ | Try by reference |
| Method Returning | R_ | |
| Method Exporting | E_ | Try to avoid |
| Method Changing | C_ | Try to avoid |
| | |
| Select-Options | S_ | |
| Parameters | P_ | |
This table is hopefully concise enough, we actually printed it on 1 DinA5, instead of the former 2 DinA4 pages.
Before starting the eagerly awaited flame war, please consider that these conventions follow those described in the book Official ABAP Programming Guidelines. of Horst Keller, Wolf Hagen Thümmel - by SAP PRESS (p. 208ff). Even if the internal SAP conventions really hurt my eyes and every SAP development team seems to use their own even more cumbersome conventions, Thank you Horst Keller for these guidelines.
No conclusion yet, we just started with these conventions and still figure out how to transform the existing code-base in a pragmatic approach...
Tools
Code-Inspector Test based on CL_CI_TEST_SCAN to limit the allowed Lines of code (Will release that soon...)
We are using smartDevelop but still need to figure out a good transformation-strategy.
Thank you for your attention, any comments appreciated.
