ABAP Programming Guidelines

1CD103

ABAP Programming Guidelines

How They Can Help You to Improve

the Quality of Your Code

Horst Keller, Chris Swanepoel, TD Core AS&DM ABAP

October 2009

SAP AG 2009. All rights reserved. / Page 2

Disclaimer

The information in this presentation is confidential and proprietary to SAP and may not be

disclosed without the permission of SAP. This presentation is not subject to your license

agreement or any other service or subscription agreement with SAP. SAP has no obligation to

pursue any course of business outlined in this document or any related presentation, or to

develop or release any functionality mentioned therein. This document, or any related

presentation and SAP's strategy and possible future developments, products and or platforms

directions and functionality are all subject to change and may be changed by SAP at any time

for any reason without notice. The information on this document is not a commitment, promise

or legal obligation to deliver any material, code or functionality. This document is provided

without a warranty of any kind, either express or implied, including but not limited to, the implied

warranties of merchantability, fitness for a particular purpose, or non-infringement. This

document is for informational purposes and may not be incorporated into a contract. SAP

assumes no responsibility for errors or omissions in this document, except if such damages

were caused by SAP intentionally or grossly negligent.

All forward-looking statements are subject to various risks and uncertainties that could cause

actual results to differ materially from expectations. Readers are cautioned not to place undue

reliance on these forward-looking statements, which speak only as of their dates, and they

should not be relied upon in making purchasing decisions.

2 SAP AG 2009. All rights reserved. / Page 3

Agenda

1. Why Programming Guidelines?

2. Building ABAP Programming Guidelines

3. The ABAP Programming Guidelines

General Basic Rules

ABAP Specific Basic Rules

Structure and Style

Architecture

Safe and robust ABAP

4. Conclusion and Outlook


Why Programming Guidelines?

Programming Practices

There are good programming practices and bad programming

practices (a generally accepted fact)

Programming guidelines support good programming practices

and try to reduce bad programming practices

In most cases, bad programming practices are not really a

problem for the ABAP Compiler and the ABAP Runtime

Environment

But bad programming practices are a big problem for

human beings!



Source code is (still) handled by human beings:

The author must understand his own programs even after a longer break

Other developers must understand an authors program for example during code inspections

Other developers who have to modify or to enhance code must understand that code

Maintainers must read and understand code that is passed to their maintenance organization

Source code must be readable, understandable and unmistakable for human readers



Human beings as the center of attention

Program authors

Other developers

Maintainers

And last but not least users!

Programs must

perform correctly

be usable and barrier free

be readable and maintainable

be robust and follow its authors intention



Following programming guidelines will result in programs that are

correct

robust

well structured

readable

maintainable

Many of these aspects are independent of the programming

language but ABAP has some peculiar aspects that must be

considered in

ABAP Programming Guidelines


Agenda




General Basic Rules


Structure and Style

Architecture




Building ABAP Programming Guidelines

There has always been demand from ABAP application programming for

central ABAP Programming Guidelines from SAP Basis

Many departments and even customers have created their own ABAP

Programming Guidelines

The ABAP Language Group began to work seriously on ABAP

Programming Guidelines for general use

An SAP-internal project was started in order to create general ABAP

Programming Guidelines as a process standard



Many rules were readily available but hidden in the ABAP Keyword Documentation



A first version was published in the year 2006 as a series of three articles in

the SAP Professional Journal that attracted an unexpected wide interest

(Available internally in SAP Corporate Portal and externally in SDN)



Based on these articles an SAP-internal SAP Programming Guide-line

(ABAP) was created by demand of SAPs maintenance organizations and established as an internal process standard in the year 2007



Autumn 2009, the English version of the ABAP Programming Guidelines

is published

German version

available since

spring 2009



The ABAP Programming Guidelines are based on such generally accepted

guidelines for good programming practices. They present them in an ABAP

specific way and add some ABAP specific rules

The ABAP Programming Guidelines are based on the preceding work

and on existing programming guidelines available for different languages

From almost all language specific programming guidelines, a common

and language independent basis can be extracted that defines the

essence of good programming

These rules tackle much more than mere questions of style (i.e. more

than the notorious naming conventions)



consist of about 120 rules divided into the subjects

General Basic Rules


Structure and Style

Architecture


cover an area that spans

from very general subjects like

Separation of Concerns

to very special subjects like

Usage of COLLECT for internal tables

The ABAP Programming Guidelines



The rules of the ABAP Programming Guidelines are classified by four

main categories

Readable Programs

ABAP Specifics

Programming Model

Correct and Robust Programs



Each rule of the ABAP Programming Guidelines is accompanied by further

information

Background Information

Rule

Detail Information

Bad Example

Good Example



The rules of the ABAP Programming Guidelines are made for all kinds of

ABAP programmers and especially experienced ones in order

to show a way through the

jungle of possibilities of

the ABAP programming

language

10


Agenda




General Basic Rules


Structure and Style

Architecture




Agenda




General Basic Rules


Structure and Style

Architecture



11



General Basic Rules

Three general basic rules concerning

Separation of Concerns (SoC)

KISS

Correctness and Quality

These rules are independent of the programming

language in use


good

Separation of Concerns


General Basic Rules - SoC

Classical Programming

bad

Separate the concerns

12



General Basic Rules - KISS

goodbad Keep it simple, stupid

Keep it small and simple

Keep it sweet and simple

Keep it short and simple

Keep it simple and smart

Keep it strictly simple

Keep it simple and

straightforward

Follow the KISS principle



General Basic Rules Correctness and Quality

Each professional organization producing software has a set of

standards that define correctness and quality.

Existing standards must be adhered to.

Standard compliance must be checked with appropriate tools.

Examples for standard relevant subjects:

Accessibility

Documentation

Functional Correctness

Globalization

Performance

Security

Usability

good

13


Agenda




General Basic Rules


Structure and Style

Architecture






Four ABAP specific basic rules

Use ABAP Objects

Choose appropriate program type and attributes

Use modern ABAP

Use all available ABAP tools to check the correctness of your

programs

14


good


ABAP Specific Basic Rules ABAP Objects

ABAP Objects offers the best means for

Data encapsulation

Explicit object instantiation

Improved code reuse via inheritance

Standalone interfaces

Explicit event raising and handling

Additionally

ABAP Objects offers one concept for everything

ABAP Objects has a stricter syntax check

ABAP Objects is used by modern ABAP technology

Always use ABAP Objects to support the separation of concerns

bad



ABAP Specific Basic Rules Program Attributes

Choose appropriate program types and attributes

Program Type

Class and Interface Pools for global Object Types (trivial)

Subroutine Pools for local functionality not visible to public (unnecessary in encapsulated

packages)

Function Pools and Executable Programs where necessary for technical reasons

No Module and Type Pools any more

Program Attributes

Unicode Checks Active switched on

Fixed Point Arithmetic switched on

No Logical Database

Original Language

Original language set for project is mandatory for all Repository Objects of the project

In monolingual development, original language is the native language of the developers

In multilingual development, original language is a language understood by all developers

(English)

15


good


ABAP Specific Basic Rules Modern ABAP

Dont use statements that are marked as obsolete*

bad

*Listed in Appendix of the book



ABAP Specific Basic Rules Check Tools

Syntax Check

No warnings from Syntax Check

Extended Check

No messages from Extended Check

Code Inspector

No messages from the standard variant of Code Inspector

ABAP Testcockpit (ATC)

No messages from ATC

Usage of Pragmas and Pseudo Comments is encouraged where appropriate

Programs must be free from errors and warnings

16


Agenda




General Basic Rules


Structure and Style

Architecture





Structure and Style

About 25 rules for structure and style dealing with

Source code format

Naming conventions

Source code comments

Structure of programs and procedures

Source code organization

Alternative forms of spelling

Complexity

17


good


Structure and Style Source Code Format

No mixed or camel case style

Maximally one statement per line

Use Pretty Printer with common settings

Do not make full use of the maximal line width

bad



Structure and Style Naming Conventions

Names must be in English

Names must be meaningful and problem-oriented

Prefixes for repository objects: CL_, IF_, CX_

Prefixes for internal objects: g_, i_, e_, c_, r_

Minimal formalistic requirements to circumvent hiding of global names

Prefixes can be enhanced by each organization (SAP, Partners, Customers)

what about KISS?

18


good


Structure and Style Source Code Comments

Comments must be in English

Comment why and not how

Align comments appropriately

Comment lines for implementations are placed before the statement blocks and indented

accordingly. Therefore, they are introduced by "

Comment lines introduced by * are either header lines or disabled code

Real line-end comments are reserved for declarative statements and to denote block-ends

bad


good


Structure and Style Program/Procedure Structure

Only one global data area for program

No further local data areas within procedures

Place global declarations in a central position at the top of a program

Place local declarations a the top a procedure

bad

19


good


Structure and Style Source Code Organization

Reuse of Include programs is highly problematic regarding

Maintainability

Resource allocation

Semantic context

Use Include programs to organize large programs

Do not reuse code of Include programs

bad


good


Structure and Style Alternative Spellings

Chained statements can even jeopardize functional correctness!

Use unique spelling within a program

Avoid chained statements in implementations

Use short forms for method invocations

Prefer operators to statements

bad

20


good


Structure and Style Complexity

Restrict the complexity of expressions

Restrict the nesting depth of control structures to 5

Restrict the number of operational statements of processing blocks to 150

Restrict the size of classes

Remove dead code

Complex structures can even jeopardize performance!

bad


Agenda




General Basic Rules


Structure and Style

Architecture



21



Structure and Style

About 25 rules for architecture dealing with

Usage of ABAP Objects

Error handling

User interfaces

Persistent data



Architecture Usage of ABAP Objects

Exploit all possibilities for encapsulation

Modularize dont atomize

Avoid static classes

Avoid deep inheritance hierarchies

Address interface components using interface reference variables

good

bad

22


good


Architecture Error Handling

Choose appropriate error handling (exception/assertion/message)

For exception handling use only class based exceptions

with appropriate exception category

with appropriate exception texts

with appropriate semantics

Decide carefully between handling and propagating exceptions

Make use of assertions

Use messages only for classical screens or exception texts

bad


good


Architecture User Interfaces

Prefer Web Dynpro ABAP to classical screens

Encapsulate classical screens in function groups

Use ALV instead of classical lists

Care for accessibility

bad

23


good


Architecture Persistent Data

Design your persistency layer carefully

Prefer Open SQL to Native SQL and ADBC

Avoid explicit client handling

Use Shared Objects for explicit buffering

bad


Agenda




General Basic Rules


Structure and Style

Architecture



24



Structure and Style

About 60 rules for safe and robust ABAP dealing with

Data types and data objects

Data handling

System fields

Internal tables

Modularization units

Dynamic programming

Internationalization



Safe and Robust ABAP Data Types and Objects

Use standalone data types

Declare data types and constants in the appropriate context

Avoid inclusion of structures, declare substructures instead

Reuse only appropriate data types

Declare dependent data objects with LIKE

Avoid table work areas

Avoid literals (magic numbers)

Prefer strings to text or byte fields

Start values must correspond to data type

badgood

25


good


Safe and Robust ABAP Data Handling

Avoid conversions

Avoid invalid values

Do not exhaust the conversion rules

Use a common notation for numeric values

Choose an appropriate numeric type

Avoid unnecessary rounding errors

Avoid implicit castings

Do not pass global data to local contexts by reference

bad


good


Safe and Robust ABAP System Fields

Never write to system fields

Never use obsolete or internal system fields

Evaluate system fields in correct positions

Always evaluate sy-subrc

Do not pass system fields to procedures

Never use system fields on screens

bad

26



Safe and Robust ABAP Internal Tables

Choose appropriate kind of table (standard/sorted/hashed)

Use secondary keys when beneficial

Set the INITIAL SIZE only if necessary

Choose appropriate output behavior (INTO/ASSIGNING/REFERENCE INTO)

Do not change the complete table within a loop

good

bad


good


Safe and Robust ABAP Modularization Units

No implementations in function modules and subroutines

Choose appropriate formal parameters

kind (importing/exporting/changing/returning)

pass by reference or value

typing

Avoid external calls of local methods and subroutines

Leave procedures using RETURN

No implementations in dialog modules and classical event blocks

Use macros only in exceptional cases

bad

27



Safe and Robust ABAP Dynamic Programming

Use dynamic techniques prudently

Avoid runtime errors

Choose appropriate dynamic data objects (pay attention to administration costs)

Avoid memory overflow and memory leaks

Use field symbols for value semantics and data references for reference semantics

Prefer dynamic tokens to program generation

bad

good


good


Safe and Robust ABAP Internationalization

All texts that are visible to users must be translatable

No anonymous placeholders in messages

Change the language environment only prudently

Restrict source code to 7-bit ASCII characters

Split text prudently

bad

28


Agenda




General Basic Rules


Structure and Style

Architecture




Conclusion and Outlook

Conclusion


comprise

explain

exemplify

rules to improve the quality of your code in a central position

For more information, check it out!

29


Conclusion and Outlook

Outlook

Re-integration of the ABAP Programming Guidelines into the

ABAP Keyword Documentation

Thank You!

30

ContactFeedback

Please complete your session evaluation.

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


Further Information

Related SAP Education and Certification Opportunities

http://www.sap.com/education/

SAP Public Web:

SAP Developer Network (SDN): www.sdn.sap.com

Business Process Expert (BPX) Community: www.bpx.sap.com

SAP BusinessObjects Community (BOC): www.boc.sap.com

SAP PRESS: http://www.sap-press.com

31


Virtual SAP TechEd :

Extend your SAP TechEd Year Round

Best of SAP TechEd at Your fingertips

View sessions that you missed

Replay and review sessions that you

attended

Quality SAP TechEd Training

Best Practices

Product Roadmaps

Learn at your own pace

Gain Access to sessions recorded in

2006, 2007, 2008 and

2009* (*available December 2009)

24/7 Access online/offline

Flexible Course Syllabus

Volume Licensing

Special Pricing for multiple subscribers

http://www.sdn.sap.com/irj/scn/virtualteched-allsessions


No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warrant.

Copyright 2009 SAP AG

All Rights Reserved

Documents

ABAP Programming Guidelines