abap_it software development guidance l3

8/13/2019 ABAP_IT Software Development Guidance L3

1/17

IT Software Development

Guidelines

Version: 1.0

Status: Draft

Date: 30/10/2013

Target group: IT ERGO Belgium

Classification:

Valid From:

Internal

30-OCT-2013


2/17

IT Software Development Guidelines Dominique Sieradzki Version: 1.0

Document1 page: 2/17

Document history

Version Responsible person Author Changes Completed

0.1 Dominique Sieradzki Dominique Sieradzki Creation 10-OCT-2013

1.0 Dominique Sieradzki Dominique Sieradzki Adjusted numbering toISO 27001

1.0.1 Geert Praet ABAP -add 30/10/2013


3/17



Preamble

The awareness for IT Good Practices at ERGO Belgium IT is raised since a long time and with the

number of Service Desk tickets increasing induced especially by non controlled way of coding.

As a response to this need code of practice documents are build.

This code of practice document targets:

IT software development/code

Objective

This guidance describes general Good Practices and standardization for IT software development at

ERGO Insurance Belgium. These Good Practices aim at ensuring the quality of the code delivered to

be delivered, as well as building knowledge and easing the maintenance.

It complements the general Development Guidance xxx.

Rem: indicate for each guidance topic whether manual or enforced by automation (will be used to

define the Code Review checks)


4/17



1 Application area

This guideline is applicable on the following Technology/(ies) used at ERGO IT: ABAP


5/17



2 Responsibilities

Developer

Team Leader

Code reviewer

Unit tester


6/17



3 Organisation

3.1 File location and storage

Fileservers of ITERGO in Dusseldorf

- The fileservers are located Dusseldorf at ERGO and administrated by ITERGO (Germany)

3.2 Versioning

Standard SAP

http://help.sap.com/saphelp_nw04s/helpdata/en/87/0a6b3ae886e511e10000000a114084/content.htm

3.3 Tooling to support development

Standard SAP


7/17


8/17



5 Coding strategy

5.1 Code convention

Most people agree that coding conventions improve software quality,since it makes thesource code easier to read. This improved readability gives a lot of benefits, such as:

Faster development since the original programmer is the first to benefit from the improvedreadability.

Code conventions improve the readability of the software, allowing programmers tounderstand new code more quickly and thoroughly.

Better cooperation within the development team since everybody can read and understandeverybody else's code.

The produced software will be easier to maintain since it isn't dependent on the originaldeveloper.

80% of the lifetime cost of a piece of software goes to maintenance.

Hardly any software is maintained for its whole life by the original author.

For the conventions to work, every person writing software must conform to the code conventions.

Everyone.

5.1.1 Program Structure

Structure your program in a way that the program is always legible for yourself and

others, and be consistent with it.

Dont write endlessly long stretches of code, but split it into logical parts using forms

with clear non-cryptical naming. (ex. write_file, check_input, process_header, )

Put a line of comment after each small part of logic, this makes the program easier to

follow for the people that have to work on it after you.

Try to outsource building blocks of business logic into BAPIs. This separates the

application logic from the business logic.

5.1.2 Data and Type Definition

Put most of the type definitions and data statements in a separate TOP include, thisreduces clutter and increases reusability.

No hard-coded values are allowed, all these values should be declared as a Constant

in the data definition section. When the constants are reused in the larger parts of the

development (e.g. company code BE10), an ABAP class can be considered to store

these constants into the attributes.

Have a fixed order for your data definitions to increase readability: for example:

Types Constants Tables

Structures Variables Field-symbols


9/17



For your data statements, use TYPE TABLE OF and TYPE instead of LIKE, which is

outdated.

5.1.3 Error Handling and Traceability

All BAPI's need to be provided by a return table or structure, this variable will have

the line-type or structure of bapiret2. The corresponding messages will be created in

the different T100 message classes.

This way, the messages can be reused within the application log as well as within

web-applications.

For the application log, consultable via slg1, a set of functionalities is already

provided in the system and thus preferably used. The includes SBAL_CONSTANTS and

Z_BALLOG_FUNCTIONS contain the necessary blocks to update the application log

5.2 ABAP naming conventions

Naming Convent ion Descr ipt ion/Usage

GV_ Global variable

GT_ Global table

GS_ Global structure (header line of table)

GC_ Global constant

T_ Type definition

LV_ Local variableLT_ Local table

LS_ Local structure (header line of table)

LC_ Local constant

P_ Input parameter

S_ Select option

O_ Business object instance

LCL_ Local Class definition

5.3 Function module parameter standards

Naming Convent ion Descr ipt ion/Usage

IV_ Importing variable

IT_ Importing table

IS_ Importing structure

EV_ Exporting variable

ET_ Exporting table

ES_ Exporting structure

CV_ Changing variable

CT_ Changing table


10/17



CS_ Changing structure

5.4 Conventions for WebDynpro

Object Naming Convent ion

Component usage U_

Inbound-Plug IP_

Outbound-Plug OP_

View (in WD Component) V_

Web Dynpro Application Z

_WD_

Web Dynpro Component Z

_WD_

Windows W_

: PROJECT

Object Naming Convent ion

BusinessGraphics BGR_

Button BTN_

ButtonRow BTR_

Caption CPT_

Checkbox CHK_

DropDownByIndex DDI_

DropDownByKey DDK_

FileUpload FUD_

Group GRP_

HorizontalGutter HOG_InputField INP_

InteractiveForm IFO_

Label LBL_

LinkToAction LTA_

LinkToURL LTU_

RadioButton RBT_

RadioButtonGroupByIndex RBI_

RadioButtonGroupByKey RBK_

RoadMap RMP_

RoadMapStep STP_

Table TBL_

TextEdit TXE_

TextView TXV_

TimedTrigger TTR_

TransparentContainer TCO_

Tray TRY_

Tree TRE_

TreeItemType TIT_

TreeNodeType TNT_

ViewContainerUIElement VCU_


11/17



5.5 Comments

??

5.6 General strategy

5.6.1 Program readability & portability

5.6.2 Program structure


12/17



5.6.3 Modularization and data declaration


13/17


14/17



6 Design Patterns

??


15/17



7 Security Hardening

Standard SAP + Standard Alice :

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4f/4decf806b02892e10000000a42189b/frameset.

htm


16/17



8 References


17/17



9 Appendixes

abap_it software development guidance l3

Documents