programming standards

[former_member222933]

what are theprogramming standardsfollowed?

[Former Member · Accepted solution]

goto this link

http://www.ams.utoronto.ca/Assets/output/assets/Developmentstandards_guidelines_335678.pdf.pdf

[Former Member]

Hi kadam,

Refer to this link.

its a pdf and has all the details that u wud need to know about programming standards.

assign points if u find it useful.

Regards,

Archna

[Former Member]

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. "