# ABAP Naming Convention Template

> Source: https://netray.co/tools/abap-naming-convention-template
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

A fill-in development standard that defines prefixes for variables, parameters, classes, DDIC objects, programs and CDS views.

## Category

sap

## Erp

SAP ECC / S/4HANA

## Audience

- ABAP developer
- SAP development lead
- SAP architect

## Tool

**Kind:** template

**Output:** document

**Fields:**

#### Company name

**Key:** company

**Type:** text

**Default:** Acme Precision Ltd

#### Customer namespace prefix

**Key:** ns

**Type:** text

**Default:** Z

**Help:** Z or Y, or a registered namespace such as /ACME/.

#### Area code example

**Key:** area

**Type:** text

**Default:** SD

#### Package example

**Key:** package

**Type:** text

**Default:** ZSD_ORDERS

#### Standard owner

**Key:** owner

**Type:** text

**Default:** Head of SAP Development

#### Effective date

**Key:** date

**Type:** date

**Default:** 2026-10-20

**Blocks:**

#### ABAP Development Naming Standard

**Body:** Company: {{company}}
Owner: {{owner}}
Effective: {{date}}

Purpose: give every custom object a predictable name so that developers can find, review and transport it. Names use the prefix {{ns}} and an area code such as {{area}}. Example package: {{package}}.

#### 1. Repository objects

**Table:**

**Columns:**

- Object
- Pattern
- Example
- Max length

**Rows:**

**0:** Package

**1:** {{ns}}<AREA>_<TOPIC>

**2:** {{package}}

**3:** 30

**0:** Report program

**1:** {{ns}}R_<AREA>_<PURPOSE>

**2:** {{ns}}R_{{area}}_OPEN_ORDERS

**3:** 40

**0:** Class

**1:** {{ns}}CL_<AREA>_<PURPOSE>

**2:** {{ns}}CL_{{area}}_PRICING

**3:** 30

**0:** Interface

**1:** {{ns}}IF_<AREA>_<PURPOSE>

**2:** {{ns}}IF_{{area}}_PRICING

**3:** 30

**0:** Exception class

**1:** {{ns}}CX_<AREA>_<PURPOSE>

**2:** {{ns}}CX_{{area}}_NO_PRICE

**3:** 30

**0:** Function group

**1:** {{ns}}FG_<AREA>_<TOPIC>

**2:** {{ns}}FG_{{area}}_UTILS

**3:** 26

**0:** Function module

**1:** {{ns}}<AREA>_<ACTION>

**2:** {{ns}}{{area}}_GET_PRICE

**3:** 30

**0:** Transaction code

**1:** {{ns}}<AREA><NN>

**2:** {{ns}}{{area}}01

**3:** 20

#### 2. Dictionary objects

**Table:**

**Columns:**

- Object
- Pattern
- Example
- Max length

**Rows:**

**0:** Database table

**1:** {{ns}}T<AREA>_<NAME>

**2:** {{ns}}T{{area}}_ORDER_EXT

**3:** 16

**0:** Structure

**1:** {{ns}}S<AREA>_<NAME>

**2:** {{ns}}S{{area}}_ORDER_LINE

**3:** 30

**0:** Table type

**1:** {{ns}}TT_<AREA>_<NAME>

**2:** {{ns}}TT_{{area}}_ORDER_LINE

**3:** 30

**0:** Data element

**1:** {{ns}}DE_<AREA>_<NAME>

**2:** {{ns}}DE_{{area}}_PRIORITY

**3:** 30

**0:** Domain

**1:** {{ns}}DO_<AREA>_<NAME>

**2:** {{ns}}DO_{{area}}_PRIORITY

**3:** 30

**0:** CDS basic view

**1:** {{ns}}I_<Name>

**2:** {{ns}}I_SalesOrder

**3:** 30

**0:** CDS consumption view

**1:** {{ns}}C_<Name>

**2:** {{ns}}C_SalesOrderList

**3:** 30

**0:** Message class

**1:** {{ns}}<AREA>

**2:** {{ns}}{{area}}

**3:** 20

#### 3. Variables and parameters

**Table:**

**Columns:**

- Kind
- Prefix
- Example

**Rows:**

**0:** Local variable

**1:** lv_

**2:** lv_matnr

**0:** Local structure

**1:** ls_

**2:** ls_header

**0:** Local internal table

**1:** lt_

**2:** lt_items

**0:** Local object reference

**1:** lo_

**2:** lo_alv

**0:** Local data reference

**1:** lr_

**2:** lr_data

**0:** Local constant

**1:** lc_

**2:** lc_status_open

**0:** Global variable, structure, table

**1:** gv_, gs_, gt_

**2:** gt_data

**0:** Class attribute (instance)

**1:** mv_, ms_, mt_, mo_

**2:** mv_plant

**0:** Class attribute (static)

**1:** sv_, ss_, st_, so_

**2:** sv_counter

**0:** Importing parameter

**1:** iv_, is_, it_, io_

**2:** iv_matnr

**0:** Exporting parameter

**1:** ev_, es_, et_, eo_

**2:** es_result

**0:** Changing parameter

**1:** cv_, cs_, ct_, co_

**2:** ct_items

**0:** Returning parameter

**1:** rv_, rs_, rt_, ro_

**2:** rv_valid

**0:** Field symbol

**1:** <lv_>, <ls_>, <lt_>

**2:** <ls_item>

**0:** Local type

**1:** ty_, ts_, tt_

**2:** ty_item

**0:** Selection screen parameter

**1:** p_

**2:** p_werks

**0:** Select-options

**1:** s_

**2:** s_matnr

#### 4. Rules

**Body:** 1. Names are in English and describe the business meaning, not the technology.
2. Use meaningful names, avoid single letters except for loop counters.
3. Do not reuse standard SAP names or the SAP namespace.
4. One class has one purpose. Prefer classes and interfaces to new function groups.
5. Every custom object belongs to a package and a transport request.
6. Exceptions to this standard need approval by {{owner}}.

#### Approvals

**Signatures:**

- Prepared by
- SAP development lead
- SAP architect

**Notes:** This is a starting point, adapt it to your landscape and to any existing SAP-delivered or partner namespace rules. Length limits shown are the usual DDIC and repository limits, check them in your release. Prefix schemes such as lv_ and ls_ are a team choice, newer clean ABAP guidance suggests dropping some prefixes, so agree the rule once and apply it consistently.

## Content

**Intro:** A naming standard keeps custom code searchable and reviewable, and it saves hours in code reviews and transports. This template generates a ready-to-adopt ABAP naming convention document with your namespace, area codes and owner, which you can export to Word or PDF.

**Sections:**

#### How to use the template

**Body:** Enter your company name, the namespace prefix you use, an example area code and the owner of the standard. The tables update with your values. Review each row with your team and change patterns that conflict with your existing objects, because a standard that contradicts the system you already run will be ignored. Export it, attach it to your development guidelines and cite it in code review comments.

#### What a good ABAP naming standard covers

**Body:** It covers three things: repository objects such as packages, programs and classes, dictionary objects such as tables, data elements and CDS views, and the prefixes inside the code itself. Length limits matter because database table names are limited to 16 characters, classes and function modules to 30, and programs to 40, so patterns must leave room for a meaningful name. Reserve the Z or Y namespace, or a registered namespace, to avoid collisions with SAP objects.

**Bullets:**

- Package and transport rules so objects are always assigned
- Class, interface and exception class patterns
- Variable, parameter and type prefixes inside code

#### Prefixes or no prefixes

**Body:** Hungarian-style prefixes such as lv_ and ls_ are widespread in SAP projects and remain acceptable. Clean ABAP guidance suggests avoiding encodings that add little, and favours good descriptive names and small methods. Either choice works if it is consistent. What does not work is a mixed codebase where each developer picks their own. Decide, document and enforce it with ABAP Test Cockpit checks where possible.

#### Common mistakes

**Body:** Teams write a long standard nobody reads, keep it outside the repository, or forget to set rules for CDS views, enhancement implementations and test classes. Others forget the 16 character table limit and find their pattern produces names that do not fit. Keep the document short, version it, and review it once a year when your release level changes.

**Cta:** If you are standardising a large custom code base before an S/4HANA move, we can discuss how AI-assisted analysis could help you find and classify what is worth keeping.

**Faq:**

#### Should custom objects start with Z or Y?

**Answer:** Both are reserved for customers. Many companies use Z for production objects and Y for temporary or sandbox ones. A registered namespace in slashes is the alternative, used by partners and software vendors who deliver add-ons.

#### Are lv_ and ls_ prefixes still recommended?

**Answer:** They are still common and widely understood, but the Clean ABAP style guide sees them as optional. The key is to be consistent inside your organisation and to name by business meaning.

#### What are the length limits for custom objects?

**Answer:** Typical limits are 16 characters for transparent table names, 30 for data elements, structures, classes and function modules, 26 for function groups, and 40 for programs. Confirm them for your release when you define patterns.

#### How do I enforce the standard?

**Answer:** Use ABAP Test Cockpit checks for naming conventions, add the document to your code review checklist, and reject transports that break it. Manual review alone fades quickly as the team grows.

## Search terms

abap naming conventions, abap coding standards template, abap variable prefix lv_ ls_ lt_, sap custom object naming convention, z namespace naming standard sap, abap development guidelines document, abap clean code naming

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json