session id: cd200 abap objects – programming guidelines

Session ID: CD200ABAP Objects – Programming Guidelines

Best Practices

Administrative Issues

Introduction

Fundamental and Formal Criteria

SAP AG 2005, SAP TechEd ’05 / CD200 / 4

Learning Objectives

As a result of this lecture, you will be able to: A set of ABAP programming conventions that every

ABAP programmer should use in new and ongoing ABAP development projects

These conventions govern: General program layout and programming model Some best practices and restrictions on the usage of language

elements Usage of test tools and other administrative issues

Best Practices


Introduction



Introduction – Motivation

Why ABAP Programming Guidelines? ABAP Objects is a modern object oriented language providing

all the features and possibilities known in object oriented development

Like in any other modern OO language there are often several ways to implement a specific solution for a given task, smart ones and not so smart ones

Additionally ABAP Objects offers special features, usually not available in other environments, to create especial performing, scalable and robust business applications

This lecture will give basic guidelines when and how to use the many possibilities ABAP Objects gives to business application developers


Introduction – Aim

Aim of the ABAP programming conventions is to support the development of:

correct

maintainable

well-structured

performing

readable

up-to-date

robust

ABAP programs.

The conventions cover formal as well as conceptual guide lines.


Introduction – Limitation

It is not the aim of this lecture to provide a general programming guide containing generalities as:

KISS (Keep It Simple Stupid)

Simple is better than complex

Clear is better than cute

Save is better than insecure

Some overhead is unavoidable …

Best Practices


Introduction


Fundamental Rules

Formal Rules


Fundamental Rules – ABAP Objects

Situation ABAP supports

An object oriented programming model based on classes and interfaces

A classical procedural programming model based on function modules, subroutines, dialog modules, and event blocks

Rule The only programming model allowed is ABAP Objects

All coding must be implemented in global or local classes Global or local interfaces are to be used when appropriate

Exceptions: Reuse of services that are implemented in existing function modules

Implementation of new function modules, where technically necessary (usage of RFC or classical screens)

See CD158 and Appendix A


Fundamental Rules – Unicode-enabling

Situation ABAP supports

Programs that are not Unicode-enabled

Programs that are Unicode-enabled (Unicode checks active).

Rule Use Unicode-enabled programs only (Unicode checks active)

Static type checks specified more precisely

Byte and character strings processed separately

Structures handled appropriately for their type using structural equivalence rules

Uncontrolled memory manipulation no longer permitted

See Appendix B


Fundamental Rules – GUI-Programming

Situation ABAP offers

Classical Dynpros, selection screens, and lists

GUI controls

BSP

Web Dynpro ABAP

Rule Web Dynpro ABAP is to be used for new projects where available.

BSP is an intermediate technology restricted to server pages.

Classical Dynpros (including Selection Screens) can be used where SAP GUI is involves. Usage of GUI Controls is recommended.

Use appropriate controls as Advanced List Viewer (ALV) instead of classical lists.

Separate application logic from presentation logic.

Fundamental Rules

Formal Rules


Formal Rules – Program Attributes

Situation

When creating new programs, you must define the program attributes.

Rules Program Type:

Class pool/interface pool for global classes/interfacesFunction pool when technically necessary (Dynpro, RFC)Subroutine pool for local classesExecutable program when technically necessary (background processing)

No linkage to a logical database

Unicode checks active

Fix point arithmetic set


Formal Rules – Processing Blocks

Situation

ABAP offers a variety of processing blocks to implement functionality.

Rules Procedures:

Implementation of new functionality in methods onlyNew function modules when technically necessary (Dynpro, RFC)No new subroutines

Dialog modules for complex classical dynpros only

Event blocksLOAD-OF-PROGRAM can be used as constructor of function groupsFor selection screen events, see dialog modulesFrom reporting events implement only START-OF-SELECTION as entry point to

a submitted programNo implementation of list events any more

All allowed non-methods must serve as mere wrappers for a method call.


Formal Rules – Source Code Sequence

Situation

The definition of program parts is not fully regulated. Arbitrary order of processing blocks

Declarative statements not limited to the head of a program or procedure

START-OF-SELECTION can be defined implicitly or several times

Rules Define an order:

Bottom up Top downSemantic proximity inside declaration parts

Local declarations must be done at the beginning of a procedure

No declarations in dialog modules or event blocks

START-OF-SELECTION must be defined explicitly


Formal Rules – Source Code Organization

Situation

The source code of a program can be organized with: Include programs

Macros

Rules Include programs

Allowed for the source code modularization of exactly one ABAP program No reuse for type definitions, declarations, or implementationsMust follow naming conventions of the ABAP WorkbenchStrongly recommended for large programs (e.g. Top-Include)

MacrosNot allowed


Formal Rules – Coding Style

Situation

ABAP allows are large varieties of programming styles regarding e.g.: Naming conventions

Indentation

Comments

Rules Use the Pretty Printer with settings that suit you most Programs must be readable and understandable, use comments where

necessary to fulfill that rule

No strict naming conventions for internal names, but to chose meaningful names that cannot be confused with predefined names

Respect the style of your colleagues

Note: Pay attention for the hiding of external objects by internal objects.


Formal Rules – Modern ABAP

Situation

ABAP is an evolving language:

Each release new features and concepts are added to the language Functional overlap with already existing language element occurs

You can decide which language element to use for a given purpose

Rules Always use the most appropriate language elements

Adjust old statements to new language elements if those that serve the same purpose better

Use the same language for the same purpose in different statements.

Example: Use the keyword LENGTH len in type and data declarations with TYPES and DATA etc. instead of (len). The reason is to you use the same

syntax in DATA and CREATE DATA.


Formal Rules – Correct ABAP

Situation

ABAP offers two types of static program checks: Syntax check reporting errors and warnings

Extended program check reporting potential errors

Rules A program must be free from syntax warnings

A program must be free from all errors, warnings, and messages sent by the extended program check

For switching off the extended program check in special cases do not use SET EXTENDED CHECK OFF but specific pseudo comments ″#EC …

Best Practices


Introduction


ABAP Objects, Modularization, and Program Flow

Declarations

Data Processing

Data Storage and Retrieval

Dynamic Programming

Error Handling


Best Practices – ABAP Objects

Situation

Programming with classes and interfaces encompasses: real model driven usage (UML-based programming)

simple procedural method calling (simply using methods)

Rules Don’t become a slave to academic OO paradigm

Use admitted and proven 4GL-features of ABAP in classes

Use defensive programming, start always as restrictive as possible and ease the restrictions

Use local classes instead of private methods of global classes for internal modularization

Use inheritance moderately

For decoupling use events

see CD158


Best Practices – Modularization

SituationFunctionality is modularized using methods.

Rules Short is better than long

Maximum number of lines should not surpass 50 lines and maximally 10 declarations (one method per page)

Modularize don’t atomize No one line methods. Number of lines larger than seven.

Flat is better than deep Reduce complexity, cyclomatic number smaller 10


Best Practices – Parameter Interface

Situation

The parameter interface of a method is specified by: Kind of parameters (IMPORTING, EXPORTING, CHANGING, RETURNING)

Number of parameters

Kind of parameter passing (by reference or by value)

Typing of parameters

Mandatory vs. optional parameters

Rules Use functional methods with no or only few importing parameters and one

returning parameter

Create slim parameter interfaces

For the kind of parameter passing, weight performance vs. robustness. Passing by reference is better in performance Passing by value is more robust

For the typing of parameters, see generic programming

Make only those parameters mandatory for which alternating input is needed for each execution


Best Practices – Control structures

Situation

ABAP offers: Branches (IF, CASE)

Loops (DO, WHILE, LOOP, PROVIDE, SELECT)

Rules Don’t allow undefined behavior in branches

Follow the SESE (Single-Entry/Single-Exit) principle

Avoid excessive block nesting depth (3 at maximum)

Do not use the statements CHECK or EXIT outside of loops

Do not use the statement LEAVE without additions


Declarations

Data Processing


Dynamic Programming

Error Handling


Best Practices – Type Declarations

Situation

Data types can be declared globally in the ABAP Dictionary, in Type Pools, and in global Classes

or Interfaces

locally in programs, local classes and interfaces, and in procedures

Rules Do not create new type groups, use global classes or interfaces instead

Consider carefully, whether to declare global types in the ABAP Dictionary or in classes/interfaces

Reuse only global types that exactly match your needs

If the underlying built-in ABAP type is incomplete (c, n, p, x), favor standalone types over bound types.


Best Practices – Global Data

Situation

Each ABAP program has implicitly a global declaration part.

Rules Restrict global data objects declared in the global declaration part to

those that are technically necessary With ABAP Objects and without using logical databases, only classical

dynpros need global data. All other data must be declared in appropriate visibility sections of

classes or as temporary working data in methods.


Best Practices – Declaration Syntax

Situation

There are still some syntax variants for declarations that should not be used any more.

Rules Do not use the TABLES statement besides declaring an interface to

classical dynpros. Prepare for each dynpro a dedicated structure in the ABAP Dictionary

Favor TYPE over LIKE

Do not type field symbols with the addition STRUCTURE of statement FIELD-SYMBOLS.

Use only matching values behind VALUE in DATA, CONSTANTS etc.


Declarations

Data Processing


Dynamic Programming

Error Handling


Best Practices – Usage of Data Objects

Situation

Data objects are treated according to their type. When the data type does not match the expected type of an operand position, in most cases the contents are converted to the expected type.

Rules Chose the data type of a data object that matches the expected values

Avoid overflow, use TRY in critical cases

Avoid unnecessary conversions

Avoid implicit casting

Use constants instead of numeric literals

Use text-symbols instead of text literals

Assign only valid values to data objects

For numerical values in character fields use a notation with the sign on the left and without spaces

Avoid accessing initial field symbols or reference variables


Best Practices – Byte and Character Processing

Situation

For byte and character processing ABAP offers text types and byte types and a set of statements Text and byte fields have fixed, strings have variable length

Trailing blanks are ignored in most operand positions when assigning text fields and kept when assigning text strings

A structure containing only text fields can be handled as one text field

Rules Prefer strings versus text fields

Do not invent workarounds for existing language elements

Use FIND instead of SEARCH, use the new variant of REPLACE Use regular expressions (as of Release 7.0) instead of programming

your own pattern searches and replacements

Use ALL OCCURRENCES in FIND and REPLACE instead of loops


Best Practices – Internal Tables

Situation

There are three kinds of internal tables: Standard tables

Sorted tables

Hashed tables

Rules Use standard tables if they filled once, processed (sorted, read out)

later and key access to table entries is not the central operation

Use sorted tables if you need a fast key access as well as an index access to table entries

Use hashed tables if key access to table entries is the central operation


Best Practices – System Fields

Situation

System fields are filled by the ABAP runtime environment. With exception of sy-repid, system fields are variables.

Rules Never write to system fields

Never use internal or obsolete system fields Evaluate system fields directly behind the respective statements Always evaluate sy-subrc, consider usage of ASSERT

Avoid usage of a system field in a statement that sets that system field

Do not use of system fields on the screen Do not use system fields as actual parameters


Declarations

Data Processing


Dynamic Programming

Error Handling


Best Practices – Persistent Data

Situation

Persistent data can be stored in several formats and in several media: Relational database tables in the database

Data clusters in the database

Binary or text files on the application server or presentation server

Rules Storing data in relational database tables is always the first choice

Data clusters are appropriate for prepared data in non-relational format

Files can provide an interface to import or export data from or to non-ABAP systems

For reading data from database tables, do not use logical databases , you might use the Object Services Query instead (Release 7.0)


Best Practices – Shared memory

Situation

An application server’s shared memory is used implicitly for program data and buffers and can be accessed explicitly using: cross-transaction application buffers (EXPORT TO SHARED BUFFER|MEMORY)

shared objects (CREATE … AREA HANDLE)

Rules Use shared objects instead of shared buffers

You can store object structures with complex dependenciesYou can work with shared objects data directly or via shared objects methods The same memory is used simultaneously and copy-free by several users

Use shared objects either as a shared buffer or as an exclusive buffer; general shared memory programming involving many parallel read and write accesses is not supported by the locking mechanism

Access shared objects via wrapper classes

Do not use the obsolete contexts (CONTEXTS, SUPPLY, DEMAND) in the shared memory


Declarations

Data Processing


Dynamic Programming

Error Handling


Best Practices – Generic Types

Situation ABAP offers a set of built-in generic types (any, any table, c, clike, csequence, data, hashed table, index table, n, numeric, object, p, simple, sorted table, standard table, table, x, xsequence) for the generic typing of field symbols and formal parameters of procedures

Typing defines how a field symbol or formal parameter can be used in operand positions

Field symbols or formal parameters receive their complete data type in the moment of binding

Rules Type formal parameters and field symbols appropriately

Match the needs of the implementation as well as the expectation of the user Favor specific generic types, e.g. use csequence instead of any for text

processing

The more general a field symbol or interface parameter is typed, the more careful you must be when using it


Best Practices – Dynamic Data Objects

Situation

Dynamic data objects are: Data objects for which the memory consumption is not determined

by the data type

Strings and internal tables

Deep data objects

Rules Avoid runtime errors due to memory overflow

Avoid runtime errors by accessing non-existing parts of dynamic objects

Avoid administrative overhead (each dynamic data object needs about 100 bytes for administration)


Best Practices – Field Symbols and References

Situation

ABAP offers pointers via field symbols and reference variables: A field symbol is a symbolic name for a data object, to which you can

assign actual memory areas at program runtime

A reference variable is a data object that contains a reference to a (data) object

Rules Use reference variables whenever field symbols are not necessary

Use field symbols only forGeneric access to data objectsDynamic access to components of structuresCasting of data objects

Do not use field symbols if the only reason is to achieve dynamic offset/length programming


Best Practices – Dynamic Token Specification

Situation

ABAP allows you to specify tokens of many statements as the contents of data objects surrounded by parentheses.

Rules Never use dynamic token specification, where static specification is

possible Avoid runtime errors coming from wrong syntax or wrong names

Prepare correct patternsCheck the availability of addressed repository objects Test such statements thoroughlyHandle all possible exceptions


Best Practices – Program Generation

Situation

Complete ABAP programs can be generated as: Temporary subroutine pools

Programs of any type in the ABAP repository

Rules Program generation is restricted to experts

Use program generation only in cases where the other means of dynamic programming are not sufficient because of

performance issuesmaintenance issuessecurity issues

Use RTTC instead of program generation for dynamic structures


Declarations

Data Processing


Dynamic Programming

Error Handling


Error Handling – Exceptions

Situation

ABAP offers different ways to handle recoverable errors: Class-based (new) exceptions

Classical (old) exceptions

Catchable runtime errors

Rules As of release 6.10, define and throw only class-based exceptions

When you catch existing classical exceptions, map them to class based exceptions

Do not handle catchable runtime errors with CATCH SYSTEM-EXCEPTIONS, use TRY … CATCH … ENDTRY only


Error Handling – Raising Exceptions

Situation

You can reuse or define exception classes.

Rules

1. Check if an exception is appropriate If exception is too strong, use return values I exception is too weak, use assertions or exit messages

2. Describe the situation

3. Check for an existing exception class

4. Refine an existing exception class

5. Create a new exception class

see CD351


Error Handling – Defining Exception Classes

Situation

Exception classes inherit from: CX_STATIC_CHECK,

propagated if explicitly declared, check by compiler

CX_DYNAMIC_CHECK, propagated if explicitly declared, check at runtime

CX_NO_CHECK, always propagated, no check

Rules Static check for exceptions a caller of a procedure explicitly must take

care of Dynamic check for exceptions a caller usually can avoid beforehand

No check for exceptions that describe errors that might occur anywhere and cannot be expected to be handled directly

see CD351


Error Handling – Handling Exceptions

Situation

Class based exceptions are handled in a TRY – CATCH – CLEANUP – ENDTRY- construct.

Rules Catch and propagate exceptions selectively

Map low level exceptions to exceptions that are appropriate for the next level user during propagation

If necessary, do not forget to cleanup before propagating

see CD351


Error Handling – Assertions

Situation

Assertions are available via the ASSERT statement: If the condition is violated the program terminates with a runtime error,

accesses the ABAP Debugger, or creates a log entry.

An Assertion is either always active or can be activated via maintenance transaction SAAB

Rules Use frequently assertions that can be activated

Do not use assertions where exceptions are requiredDo not check conditions that are based on input parameters or

the availability of some external resource with assertions

Check only preconditions for internally used functionality with assertions Use assertions that are always active if checking s crucial

see CD351


Error Handling – Messages

Situation

Messages are texts that are displayed using the MESSAGE statement: In classical dynpro programming, messages provide an error dialog

In application programming messages can be used as a surrogate for exceptions that are combined with a text

Rules Use messages only for classical dynpro processing

Do not use messages – and in particular messages of type ‘E’ or ‘W’ – in other contexts than PAI processing

Do not use messages for exceptions Catch existing ones and map them to class-based exceptionsFor connecting exceptions with dialog texts implement the predefined

interface IF_T100_MESSAGE in the exception class Use messages of type ‘X’ with extreme care only

see CD351

Best Practices


Introduction


Testing

Documentation

Packages


Administrative Issues – Testing

Situation

The ABAP development environment offers a great variety of test tools.

Rules

Cover 100 % of your coding by appropriate tests: Perform bundled static checks with the Code Inspector

Cover your complete application coding with ABAP Unit tests

Cover your complete presentation coding with ECATT

Check the memory consumption with the Memory Inspector

Check the performance with the Performance and the Runtime Analysis

Check the program organization with the Coverage Analyzer

Testing

Documentation

Packages


Administrative Issues – Documentation

Situation

The ABAP Workbench offers a complete set of documentation tools for all kinds of repository objects.

Rules

All programs and program interfaces that are released for the usage by others must be documented: Document global classes, function groups and function modules

If the name of an (public) component and its short text(s) are sufficient, you must not necessarily provide a long text for that component

If a class, the components of a class, or a program are described somewhere else (e.g. in the Knowledge Warehouse), you must link from the specific documentation to this documentation.

Testing

Documentation

Packages


Administrative Issues – Packages

Situation

Packages are containers of (closely related) repository objects with additional semantics: Transport related properties

Access control for repository objects at design time

Nesting (layering) of packages

Rules Leverage all features of packages

Assign the application component as specific as possible

Define a package’s interface

Mark “Package check as server” Care for strong cohesion of repository objects within a package and

loose coupling between repository objects of different packages Avoid the creation of objects in a package that isn’t original in the

current system


Summary

Following some formal rules …

Utilizing some best practices …

Fulfilling some administrative issues …

… results in State-of-the-Art ABAP


APPENDIX

Questions?

A – Stricter Syntax in ABAP Objects

B – Stricter Syntax in Unicode Programs


Appendix A – Stricter Syntax in ABAP Objects (1/2)

Notation: No special characters in names, no length specifications <= zero, no multi-line literals

Declarations: LIKE references to data objects only; no implicit lengths or decimal places in TYPES; no length specifications for data types i, f, d, or t; no operational statements in structure definitions; FIELDS, RANGES, INFOTYPES, TABLES, NODES, COMMON PART, OCCURS, NON-LOCAL not permitted

Forbidden operations: CLEAR … WITH NULL, PACK, MOVE ... PERCENTAGE, ADD-CORRESPONDING, DIVIDE-CORRESPONDING, SUBTRACT-CORRESPONDING, MULTIPLY-CORRESPONDING, ADD THEN ... UNTIL ..., ADD FROM ... TO ..., CONVERT {DATE|INVERTED DATE}

String processing: Not permitted on numeric data objects Field symbols: No implicit types; FIELD-SYMBOLS … STRUCTURE,

ASSIGN ... TYPE, ASSIGN LOCAL COPY OF, ASSIGN TABLE FIELD not permitted

Logic expressions: ><, =<, => not permitted, table used with IN must be a selection table

Control structures: No operational statements between CASE and WHEN, ON-ENDON not permitted


Appendix A – Stricter Syntax in ABAP Objects (2/2)

Internal tables: No headers, no implicit work areas, no redundant key specifications, compatible work areas where necessary, obsolete READ variants and COLLECT ... SORTED BY, WRITE TO itab, PROVIDE (short form) not permitted

Procedures (methods): No implicit type assignment, compatible initial values only, passing sy-subrc not permitted, raising undefined exceptions not permitted

Program calls: No joint use of USING and SKIP FIRST SCREEN when calling transactions, passing formal parameters implicitly in CALL DIALOG not permitted

Database accesses: No implicit work areas, no *-work areas, READ, LOOP, REFRESH FROM on database tables not permitted, VERSION addition to DELETE and MODIFY not permitted, no PERFORMING addition in Native SQL

Data cluster: No implicit identifiers, passing parameters explicitly not permitted, no implicit work areas, MAJOR-ID and MINOR-ID not permitted

Lists: DETAIL, SUMMARY, INPUT, MAXIMUM, MINIMUM, SUMMING, MARK, NEW-SECTION and obsolete print parameters not permitted


Appendix B – Stricter Syntax in Unicode Programs

Offset/length accesses: Only performed on character-type or byte-type ranges, and only on flat character-type initial parts of structures

Memory accesses: No access to memory outside a data object Separation of byte string and character string processing: Explicit

specification with IN BYTE MODE or IN CHARACTER MODE ; appropriate types expected – for character strings this means only c, d, n, t, string, and flat structures with purely character-type components

Structures: When assigning and comparing you must take the Unicode fragment view into consideration

File interface: Implicitly opening files not permitted; access, storage, and coding type must be specified explicitly; no write access to read-only files

Conversions: TRANSLATE ... CODE PAGE ..., TRANSLATE ... NUMBER FORMAT ... not permitted

OPEN SQL: Stricter conditions for work areas Type assignment using STRUCTURE: Stricter checks on assignments

to field symbols and formal parameters typed using STRUCTURE Function module calls: A specified formal parameter of a function

module must be available


Public Webwww.sap.comNetWeaver Developer‘s Guide: www.sdn.sap.com/sdn/developersguide.sdn SAP Developer Network: http://www.sdn.sap.com/sdn/developerareas/abap.sdn SAP Customer Services Network: www.sap.com/services/

Articles in Journalshttp://www.intelligenterp.com/feature/archive/heymann.shtmlhttp://www.intelligenterp.com/feature/archive/keller.shtmlhttp://www.sappublications.com/insider/article.htm?key=20248Many ABAP articles at http://www.sappro.com

ABAP Keyword-DocumentationTransaction ABAPHELP, always the first source of information

Further Information

Programming Guidelines upcoming.


SAP Press BooksABAP Objects, Introduction: ISBN 0-201-75080-5 (English), ISBN 3-89842-147-3 (German)ABAP Reference:ISBN 1-59229-039-6 (English), ISBN 3-89842-444-8 (German)ABAP Quick Reference:ISBN 1-59229-057-4 (English), ISBN 3-89842-680-7 (German)for more books visit http://www.sap-press.com, http://www.sappress.de.#NetWeaver Developer‘s Guide: www.sdn.sap.com/sdn/developersguide.sdn

Further Information


Q&A

Questions?


Please complete your session evaluation.

Be courteous – deposit your trash, and do not take the handouts for the following session.

Feedback

Thank You !

session id: cd200 abap objects – programming guidelines

Documents

sap ag slide

sap teched

abap programming guidelines

abap programmer

possibilities abap objects

unavoidable slide

fundamental rules unicode

unicodeenabled unicode