Abap coding standards

Question

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

Answer 1

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