Data Objects

Session ID: CD200

ABAP Objects –

Programming Guidelines

Introduction

Fundamental and Formal Criteria

Best Practices

Administrative Issues

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



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

Introduction


Best Practices


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 g Some overhead is unavoidable …




Introduction


Best Practices


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/interfaces

 Function pool when technically necessary (Dynpro, RFC)

 Subroutine pool for local classes

 Executable 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 only

 New function modules when technically necessary (Dynpro, RFC)

 No new subroutines

 Dialog modules for complex classical dynpros only

 Event blocks

 LOAD-OF-PROGRAM can be used as constructor of function groups

 For selection screen events, see dialog modules

 From reporting events implement only START-OF-SELECTION as entry point to a submitted program

 No 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 down

 Semantic 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 implementations

 Must follow naming conventions of the ABAP Workbench

 Strongly recommended for large programs (e.g. Top-Include)

 Macros

 Not 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 …




Introduction


Best Practices


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

Situation

Functionality 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



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



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



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 dependencies

 You 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



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 for

 Generic access to data objects

 Dynamic access to components of structures

 Casting 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 patterns

 Check the availability of addressed repository objects

 Test such statements thoroughly

 Handle 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 issues

 maintenance issues

 security issues



Use RTTC instead of program generation for dynamic structures





Declarations

Data Processing



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 –

ENDTRYconstruct.

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 required

 Do 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 exceptions

 For 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




Introduction


Best Practices


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




Questions?

APPENDIX

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




Further Information



Public Web www.sap.com

NetWeaver 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/



ABAP Keyword-Documentation

Transaction ABAPHELP, always the first source of information



Articles in Journals http://www.intelligenterp.com/feature/archive/heymann.shtml

http://www.intelligenterp.com/feature/archive/keller.shtml

http://www.sappublications.com/insider/article.htm?key=20248

Many ABAP articles at http://www.sappro.com




Further Information



SAP Press Books

ABAP 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




Questions?

Q&A




Feedback

Please complete your session evaluation.

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

Thank You !




Data Objects

Session ID: CD200

ABAP Objects –

Programming Guidelines

As a result of this lecture, you will be able to:

APPENDIX

A – Stricter Syntax in ABAP Objects

B – Stricter Syntax in Unicode Programs

Q&A

Feedback

Please complete your session evaluation.

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

Thank You !

Related documents

Products

Support

Data Objects

Session ID: CD200

ABAP Objects –

Programming Guidelines

As a result of this lecture, you will be able to:

APPENDIX

A – Stricter Syntax in ABAP Objects

B – Stricter Syntax in Unicode Programs

Q&A

Feedback

Please complete your session evaluation.

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

Thank You !

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib