Programming standards

Question

what are theprogramming standardsfollowed?

Answer 1

where....
·         Use select single * from ... as much as possible. Only use select * from ... when absolutely necessary.  Select single will return only one record.  However, if you don’t specify the whole key to the table, the returned record will be any line of the records that meets the specified key.   Only use Select Single when the full key of the table is known.
·         Specifying values for as many of the table’s key fields in a WHERE clause will make the SELECT statement more efficient than checking values after the select.
·         Never use any processing statement within SELECT  ……… ENESELECT. In case it is required, populate an internal table corresponding to the table, loop at the internal table and do the processing there.
·         Specifying the ‘left-most’/least specific key fields in a WHERE clause improves  efficiency.
For example,  the key fields (in sequence) of the table KNC3 (Customer special G/L  transaction )
MANDT       -         Client         
KUNNR       -         Customer number      
BUKRS       -         Company code         
GJAHR       -         Fiscal year          
SHBKZ       -         Special G/L indicator
When selecting data from this table,  it would be more efficient to specify a value in the WHERE clause for the field KNC3-BUKRS,  rather than KNC3-GJAHR.  That is:
SELECT * FROM KNC3
      WHERE KUNNR EQ ‘0000000001’
      AND   BUKRS EQ ‘US01’.
ENDSELECT.
will be more efficient than:
SELECT * FROM KNC3
          WHERE KUNNR EQ ‘0000000001’
          AND   GJAHR EQ ‘1996’.
ENDSELECT.
·         You can specify as many WHERE conditions as you like in all types of database tables ‑ i.e.  transparent tables,  pool tables and cluster tables.  However,  you should be aware for performance reasons that complex WHERE conditions involving pool and cluster tables usually cannot be passed to the database system. They must be processed by the SAP database interface through post‑selection.
·         Selecting via non-key fields.   When selecting records from a database table when only part of a field (on which selection is based) is known,  use the LIKE option as part of the WHERE clause.
For example:
SELECT *    FROM T001G
  WHERE     BUKRS EQ   ‘US01’
  AND       TXTKO LIKE ‘__PERS%’.
ENDSELECT.
is more efficient than:
SELECT * FROM T001G
  WHERE BUKRS EQ ‘US01’.
  CHECK T001G-TXTKO+2(4) = ‘PERS’.
3.1.7.5   Defining Variables
·         When defining variable use “LIKE” as much as possible to ensure automatic consistency with the items in the R/3 tables.
·         All variables should have a description to the right of the declaration.
·         Always keep the SAP names.  DO NOT “translate”.  If you need the same type of data from different tables like document numbers for different documents, prefix the name with the table name like:
       WS_VBAK_VBELN                                         “Sales Order No.
       WS_LIKP_VBELN                                         “Delivery No.
3.1.7.6   Testing one field for multiple values
When testing an individual field for multiple values,  you can use:
IF        field  =  value1.
ELSEIF    field  =  value2.
ELSEIF    field  =  value3.
                         or
CASE  field.
    WHEN  value1.
    WHEN  value2.
    WHEN  value3.
ENDCASE.
The first method is more efficient when checking a field for up to about five values.  Beyond this, you should use the CASE statement.  At this point it becomes more efficient than the nested Ifs, and will also improve the readability of the program code
3.1.7.7   Optimizing IF and CASE structures
To optimize IF and CASE structures, always test values in order of the likelihood of each value occurring.
For example, WS_FIELDX can have values ‘A’,  ‘B’, or ‘C’.   A value of ‘B’ is the most likely value to occur, followed by ‘C’, then ‘A’.  To optimize a CASE statement for WS_FIELDX, code the CASE statement as follows:
CASE WS_fieldx.
      WHEN  ‘B’.      “Most likely value
      WHEN  ‘C’.      “Next most likely value
      WHEN  ‘A’.      “Least likely value
ENDCASE.
Here,  if WS_FIELDX has a value of ‘B’,  only one test is performed,  if it has a value of ‘C’,  two tests must be performed,  and so on.  Coding in this manner reduces the average number of tests performed by the program.
3.1.7.8   Performing Calculations
    When performing calculations in ABAP,  the amount of CPU time used depends on the data type. In very simple terms,  Integers (type I) is the fastest,  Floating Point (type F) requires more time,  and Packed (type P) is the most expensive. Normally,  Packed number arithmetic is used to evaluate arithmetic expressions. If,  however,  the expression contains a floating point function,  or there is at least one type F operand,  or the result field is type F,  floating point arithmetic is used instead for the entire expression.  On the other hand,  if only type I fields or date and time fields occur,  the calculation involves integer operations.
Since floating point arithmetic is relatively fast on SAP hardware platforms,  it should be used when a greater value range is needed and rounding errors can be tolerated.  Rounding errors may occur when converting the external (decimal) format to the corresponding internal format (base 2 or 16) or vice‑versa.
3.1.7.9   Packed Number Arithmetic
If the program attribute Fixed point arithmetic is not set, type P fields are interpreted as integers without decimal places. The DECIMALS parameter of the DATA statement only affects the format of the WRITE output.
For this reason, SAP recommends that you always set the program attribute Fixed point arithmetic when working with type P fields
3.1.7.10          Moving identical structures
Use:                 MOVE  structure1                  TO  structure2.
or                      structure2  = structure1
instead of:       MOVE-CORRESPONDING structure1         TO  structure2.
3.1.8 Commands
The following is a selected list of preferred commands along with a short functionality description of the command.  For further details, use the ABAP editor help.
3.1.8.1   Catch/EndCatch
You can catch ABAP runtime errors in the processing block enclosed in the CATCH ... ENDCATCH statements.
Syntax:  CATCH SYSTEM-EXCEPTIONS except1 = rc1 ... exceptn = rcn.      
Note the following:                                            
·         rc1 ... rcn must be numeric literals.                       
·         CATCH ... ENDCATCH may be placed anywhere where IF ... ENDIF (for example) may occur. It is local, not cross-event.      
·         It may be nested to any depth.
·         It only catches runtime errors in the current call level.  This means, for example, that runtime errors resulting from PERFORM- or CALL FUNCTION statements are not trapped by CATCH ... ENDCATCH.
Example:
PARAMETERS fact TYPE i.                                  
DATA: fact_save TYPE i,                                  
      res(16)  TYPE p.                                   
ARITHMETIC_ERRORS contains COMPUTE_BCD_OVERFLOW ***  
CATCH SYSTEM-EXCEPTIONS ARITHMETIC_ERRORS = 5.           
  res = fact_save = fact.                                
  SUBTRACT 1 FROM fact.                                  
  DO fact TIMES.                                         
    MULTIPLY res BY fact. "