abap coding standards

Former Member — Mon, 21 May 2007 11:02:14 GMT

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

Re: abap coding standards

Former Member — Mon, 21 May 2007 11:14:18 GMT

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

Re: abap coding standards

Former Member — Mon, 21 May 2007 11:19:58 GMT

hi,

See the programming standards are given by your client to follow when developing objects..

Ex:

TY_name for declaring global types,

IT_TABLE for global internal tables,

l_it_table for local internal tables,

gc_variable for global variables..

lc_var for local variables.

ty_<internlatablename>_t for Table type..

l_wa_itab for local work area.. etc..

Use for all entries for better performance..

declare work area inside subroutines where ever necessary

use field symbols instaed of using work area when Modify the internal table..

rewards if useful

regards,

nazeer..

Re: abap coding standards

ferry_lianto — Mon, 21 May 2007 11:23:42 GMT

Hi,

Welcome to SDN.

Please check this link for ABAP coding standards.

http://web.mit.edu/ist/org/admincomputing/dev/abapstds/current/

Regards,

Ferry Lianto

Please reward points if helpful.

topic abap coding standards in Application Development and Automation Discussions

abap coding standards

Re: abap coding standards

Re: abap coding standards

Re: abap coding standards