Solved: Re: abap coding standards

Former Member · ‎2007 May 21

hi can u tell me the standards that are followed in a company for ABAP CODE.

Former Member · ‎2007 May 21

There are some coding guidelines need to be followed during coding . here are a few ones

Avoid dead-code

Remove unnecessary code and redundant processing

Spend time documenting and adopt good change control practices

Spend adequate time anayzing business requirements, process flows, data-structures and data-model

ensure careful usage of "OR", "NOT" and value range tables (INTTAB) that are used inappropriately in Open SQL statements.

f you are interested in exactly one row of a database table or view, use the SELECT SINGLE statement instead of a SELECT * statement. SELECT SINGLE requires one

communication with the database system whereas SELECT * requires two.

It is usually faster to use the INTO TABLE version of a SELECT statement than to use APPEND statements

f you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates within the program. The RDBMS is responsible for aggregated computations instead of transferring large amount of data to the application. Overall Network, Application-server and Database load is also considerably less.

If you process your data only once, use a SELECT-ENDSELECT loop instead of collecting data in an internal table with SELECT ... INTO TABLE. Internal table handling takes up much more space

Using nested selects is a technique with low performance. The inner select statement is executed several times which might be an overhead. In addition, fewer data must be transferred if another technique would be used eg. join implemented as a view in ABAP/4 Repository.

Whenever possible, use array operations instead of single-row operations to modify the database tables.

Frequent communication between the application program and database system produces considerable overhead.

some best practices are :

1. Use of local variables instead of global variables - will save memory. Use global variables ony when absolutely necessary!

2. (a.) Do not change variables in the "using", use the "changing" parameters instead for this purpose

(b.) "tables" parameter is now obsolete - do NOT use

3. Inside subroutines (forms), the using and changing parameters should have reference to a "TYPE"

4. NO literals, instead use constants / text elements - as the case may be.

5. All constants should be defined globally.

6. Query on database tables within: loop.... endloop - to be strictly avoided

7. Internal table definition technique - using DDIC Structures and DDIC Table Types. Avoid defining local types in programs. Do not define internal tables with header line.

8. Initialize, clear variables/work areas before internal table reads.

9. Sort internal tables before using "delete adjacent duplicates".

10. Use the "binary search" option while reading internal tables, and sort the internal table prior to read.

11. Check that the internal table has entries (not initial) before using "for all entries" option in select statements.

12. sy-ucomm = 'ONLI'?? Is this to check if program executed online or in background? Use the sy-batch variable instead

13. Use function modules to read: Customizing and Master tables. Only Transaction tables to be directly queried.

14. SY-SUBRC check is a MUST after all function calls; and please handle the exception suitably.

15. Use of field symbols with internal tables [LOOP at itab ASSIGNING <fs>] is always a preferred/better option, as against loop at itab into <WORK_AREA>.

16. Use of too many includes ?? (We could use: one include for global data declarations, one include for class methods, one include for subroutines and probably one more include for Application logs)

17. No dead code please - remove if not required.

18. Use of case.... endcase, is preferred instead of: if.. elseif.. endif.

19. Try NOT to use "into corresponding fields of" or "move corresponding" - these are detrimental from a performance perspective

20. Instead of "select single", it is better to use "*_SINGLE_READ" function modules if available. Check always for availability of standard function modules for data retrieval from Master / Customizing tables.

21. Use of Memory ID's to be strictly avoided, as these could be overwritten globally.. Please write explicit GET, SET function modules for this purpose.

22. Locking the database before direct table updates is mandatory, database updates should always be in -> 'Update task' function modules.

23. After BAPI calls, use BAPI_TRANSACTION_COMMIT. Do NOT call BAPI_TRANSACTION_COMMIT in a loop.

24. Case 'X'. when <variable> ???? - refrain from using in this manner

25. Provide adequate inline comments, explaining what the piece of code is supposed to do / intended to achieve.

Message was edited by:

Sridhar Srirama

Former Member · ‎2007 May 21