> For the complete documentation index, see [llms.txt](https://docs.prebilt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prebilt.com/prebilt-for-im-wm-strm/enhancing-prebilt/coding-standards.md).

# Coding standards

This section details a list of coding standards used internally by TCT when developing PreBilt.

## Scope and principles

These standards are intended to keep development consistent, readable, maintainable and reviewable. They apply to TCT ABAP product development and to customer-namespace ABAP development where the customer has not supplied a complete standard. The SAPUI5 section applies as the minimum pre-code-review baseline for UI5 repositories and extensions.

* Follow the approved functional and technical design.
* Use consistent naming, layout and structure.
* Remove dead, sample and placeholder code.
* Handle errors safely and provide meaningful messages or logs.
* Test the change and run the relevant automated checks before peer review.
* Do not release workbench content until code review findings have been resolved and the code has been retested.

## Development and review lifecycle

1. Design the solution.
2. Complete the functional specification.
3. Obtain design approval.
4. Obtain build approval.
5. Build the change.
6. Run the required automated quality checks.
7. Complete unit testing and the applicable system, integration, user acceptance and performance testing.
8. Submit the code for peer review.
9. Address findings, retest and re-submit where required.
10. Release the transport or merge the change only after the review is passed.

{% hint style="info" %}
**Specifications**

The technical specification must identify all development objects and describe the code flow in pseudocode. Include flow diagrams or annotated mock-ups where they add genuine value, particularly for forms and screens.
{% endhint %}

## Common code-quality expectations

### Structure and maintainability

* Keep code well structured, readable and appropriately commented.
* Group related functions logically and place section headers before the code they describe.
* Avoid duplicate declarations and mixed indentation.
* Delete commented-out implementations rather than retaining dead code. Use version control or an ABAP version where history must be preserved.
* Remove proof-of-concept, sample and placeholder code before review.
* Check that version identifiers and related metadata are current.

### Error handling and messages

* Check for error conditions after function calls, table reads, object creation and other operations that can fail.
* Use function module exceptions correctly and check returned error tables where applicable.
* Use TRY...CATCH effectively for methods and classes that raise exceptions. If no specific action is required, catch safely rather than allowing an avoidable termination.
* For customer-facing ABAP messages, use message classes in SE91 rather than literals or text symbols.
* Maintain meaningful short text and long text for customer-facing errors unless the short text fully explains the issue.
* Use named placeholders &1 to &4 rather than anonymous placeholders.
* Include ERROR\_MESSAGE and OTHERS for standard function modules where appropriate.

## ABAP coding standards

### Quality checks and formatting

* Run Extended Program Check, ABAP Test Cockpit (ATC) and Code Inspector before system testing.
* Clear applicable errors and warnings before transport release.
* Use the customer Global Check variant where available. The project may define the Code Inspector template.
* Apply Pretty Printer to all code objects using Indent and Uppercase Keyword. In Eclipse, use Format.
* Complete a manual peer review for every form, report, enhancement, workflow, interface and data migration.

### Manual review questions

* Does the code implement the approved specification?
* Is there a more suitable SAP CDS view or indexed database table?
* Is the code structured, readable and maintainable?
* Will it cope with expected data volumes?
* Is database and internal-table processing efficient?
* Are comments, spacing and formatting clear?
* Are errors handled and messages meaningful?

### Naming conventions

Interface parameters combine the direction prefix with the data-type prefix. For example, an importing variable begins IV\_ and an exporting structure begins ES\_.

| **Object type**            | **Global prefix** | **Local prefix** |
| -------------------------- | ----------------- | ---------------- |
| Constant                   | GC\_              | LC\_             |
| Object reference           | GO\_              | LO\_             |
| Internal table             | GT\_              | LT\_             |
| Structure                  | GS\_              | LS\_             |
| Range structure            | GRS\_             | LRS\_            |
| Range table                | GR\_              | LR\_             |
| Type                       | TY\_              | LTY\_            |
| Table type                 | TT\_              | LTT\_            |
| Variable                   | GV\_              | LV\_             |
| Selection-screen parameter | P\_               | -                |
| Select option              | SO\_              | -                |

Parameter direction prefixes: I*\_ importing, E*\_ exporting, C*\_ changing and R*\_ returning. Replace \* with V, S, T, O, C or R for variable, structure, table, object, constant or range.

| **ABAP object**                      | **Naming pattern** |
| ------------------------------------ | ------------------ |
| Classes / interfaces                 | ZCL\_\* / ZIF\_\*  |
| Service                              | ZSRV\_\*           |
| Application                          | ZAPP\_\*           |
| Proxy-generated classes / interfaces | ZCO\_\* / ZII\_\*  |
| Views                                | Z\*\_V             |
| Table types                          | Z\*\_TT            |
| Enhancement ID                       | ZEH\_\*            |
| Enhancement spot                     | ZES\_\*            |
| Search help                          | Z\*\_SH            |
| Lock object                          | EZ\*               |
| Include                              | ZI\*               |
| Module pool                          | SAPMZ\*            |
| Executable program                   | Z\*                |
| Data element                         | Z\*\_DE            |
| Domain                               | Z\*\_D             |

| **View object**      | **Convention**                                    |
| -------------------- | ------------------------------------------------- |
| CDS view entity      | ZI\_BasicViewName                                 |
| CDS table function   | ZTF\_TableFunctionName                            |
| CDS consumption view | ZC\_ConsumptionViewName                           |
| CDS value help       | ZI\_BasicViewNameVH or ZI\_BasicViewNameValueHelp |
| CDS text             | ZI\_BasicViewNameText                             |
| CDS cube             | ZI\_BasicViewNameCube                             |
| CDS query            | ZI\_BasicViewNameQuery                            |
| CDS access control   | Same name as the protected object                 |

Use CamelCase for CDS view fields rather than underscores.

### Field symbols and inline declarations

* Use inline declarations where possible in supported ABAP releases.
* Apply the global or local naming prefix that matches the field symbol scope and type.
* After assigning a structure component or reading an internal table into a field symbol, check SY-SUBRC before using the field symbol.
* For supported releases, line\_exists( ) can be used to test whether an internal-table row exists.
* Where an inline declaration does not make the intended type sufficiently clear, choose an explicit declaration that makes the type and purpose unambiguous.

### Enhancements and modifications

* Use implicit enhancements only after standard alternatives have been exhausted. Document why they are needed and which alternatives were considered.
* Explicit enhancements are acceptable where SAP provides an enhancement spot. Add a comment block explaining the purpose.
* Treat modifications to SAP standard as a last resort. Obtain and document customer approval before work begins, and follow the required SAP registration and access-key process.

### Background processing and logging

* Background-only programs must write useful messages to the job log.
* As a minimum, report processed volumes and explain termination conditions.
* Write detailed execution results to the Application Log (SLG1) where appropriate.
* Provide the application-log ID and enough information for a support user to find the log.
* Use /TCTM/LOG\_HELPER where it is the relevant helper for TCTM service-class methods.

### Database access

* Select only the columns required. Use SELECT \* only when most columns are genuinely needed or the source is already a restricted CDS view.
* Avoid SELECT...ENDSELECT in loops and avoid nested or looped database access.
* Use JOINs or suitable CDS views to push linked-table work to the database.
* Use SELECT SINGLE when the full key is available. If one row is required without the full key, use UP TO 1 ROWS and explain in a comment why the result is deterministic and appropriate.
* Align compared field types and use available primary or secondary indexes effectively.
* Before FOR ALL ENTRIES, confirm the driver table is not empty. Sort it and remove duplicate keys where this improves the query.
* Use database aggregate functions for MIN, MAX and COUNT rather than retrieving data and calculating them in ABAP.
* For large data volumes, consider FETCH with a suitable PACKAGE SIZE and periodic commits for updates.
* Avoid using logical databases except for HR and Payroll cases where they are justified.

{% hint style="info" %}
**Review judgement**

Some database rules in the source are expressed as default preferences rather than universal absolutes. Reviewers should judge the actual access path, released SAP guidance and measured behaviour, while requiring the developer to justify exceptions.
{% endhint %}

### Internal tables

* Declare internal tables with TYPE STANDARD, SORTED or HASHED TABLE OF rather than OCCURS or header lines.
* Choose the table category and key to match the access pattern.
* Prefer LOOP AT ... ASSIGNING for in-place processing where appropriate.
* Use LOOP...WHERE rather than looping over all rows and filtering with CHECK or IF.
* Use INSERT for sorted or hashed tables. APPEND can fail when it violates sorted-table order.
* Use itab2 = itab1 or APPEND LINES OF for whole-table copies rather than row-by-row loops.
* When using DELETE ADJACENT DUPLICATES, sort by and compare the intended fields.
* Free large internal tables once they are no longer required where memory recovery is useful.

### Disallowed and discouraged constructs

| **Category** | **Rule**                                                                                     |
| ------------ | -------------------------------------------------------------------------------------------- |
| Not allowed  | Unapproved modification of SAP standard code.                                                |
| Not allowed  | Commented-out code retained as an implementation archive.                                    |
| Not allowed  | Logical databases outside justified HR/Payroll use.                                          |
| Not allowed  | SELECT...ENDSELECT except the documented single-row case where SELECT SINGLE cannot be used. |
| Not allowed  | LET, as specified by the source standard.                                                    |
| Discouraged  | Macros, except very simple repeated code that cannot fail.                                   |
| Discouraged  | INTO CORRESPONDING FIELDS OF TABLE where a purpose-built structure is clearer.               |
| Discouraged  | Implicit enhancements.                                                                       |
| Discouraged  | CHECK outside a loop.                                                                        |
| Discouraged  | OCCURS and obsolete header-line patterns.                                                    |

### Obsolete language elements

| **Avoid**                | **Use instead**                                    |
| ------------------------ | -------------------------------------------------- |
| OCCURS                   | TYPE STANDARD, SORTED or HASHED TABLE OF           |
| RANGES declaration       | TYPE RANGE OF                                      |
| REFRESH itab             | CLEAR itab                                         |
| SEARCH                   | FIND                                               |
| TABLES parameters        | USING or CHANGING parameters                       |
| WITH HEADER LINE         | Work structures or field symbols                   |
| Untyped field symbols    | A relevant data element/type, or at least TYPE ANY |
| DESCRIBE TABLE ... LINES | LINES( ... )                                       |
| Row-by-row table copy    | Direct assignment or APPEND LINES OF               |

### Table maintenance and security

* For generated table maintenance, create a dedicated SAP transaction code.
* Configure transport recording according to whether entries are intended to be transportable or maintained directly in each system/client.
* Use delivery class C for 'Standard recording routine' and A for 'No, or user, recording routine', as stated in the source standard.
* For tables updated only programmatically, set Data Browser/Table View Editing to 'Display/Maintenance allowed with restrictions'.
* The source standard specifies authorisation group \&NC& and relies on security for SM30/SM34 plus the dedicated maintenance transaction. Treat this as a project security decision and confirm it against the customer's security design before implementation.

## SAPUI5 coding and pre-review standards

The current SAPUI5 source is a practical pre-code-review checklist rather than a full implementation standard. The rules below are therefore presented as the minimum review baseline, without implying a level of design detail that the source does not contain.

### General code hygiene

* Remove commented-out code unless it is deliberately retained for future use and includes a clear reason.
* Confirm that application, controller and other version identifiers are current.
* Remove duplicate declarations.
* Use consistent indentation. Do not mix indentation widths.
* Avoid unnecessary arrow functions in controller logic where this context or named functions are important for debugging.
* Place section headings before the relevant code blocks.
* Group shared and related functions in the correct logical section.

### Linting and formatting

* Run Prettier, or the project-approved equivalent, across all relevant files.
* Resolve all ESLint errors and warnings.
* Maintain consistent spacing, casing and bracket style.
* Confirm the ESLint extension is active in VS Code before committing.

### CSS files

* Where a CSS file must exist but is otherwise empty, add a harmless comment so the file is not empty and does not trigger SAP UI5\_REPO\_LOAD errors.
* Apply the same treatment to extension CSS files where applicable.

### Controller and view responsibilities

* Perform model binding in the controller rather than duplicating it in the view.
* Handle press events in the controller.
* Bind LiveChange events for search fields in the controller only.

### Extensions and sample code

* Remove sample, placeholder and proof-of-concept code from extensions.js.
* Use a clean template where a starting structure is required.
* Do not retain full commented-out implementations.

### Testing and version-control workflow

* Keep automated tests current and store them in the correct /tests/ directory.
* Use Playwright for smoke and regression tests in accordance with the separate Automated Testing Guidelines.
* Create and label GitLab issues for test changes.
* Use feature branches and submit merge requests to the test-dev branch.

## Pre-review checklists

### ABAP developer checklist

* [ ] Specification and object list are complete.
* [ ] Naming conventions are followed.
* [ ] Pretty Printer or Eclipse Format has been applied.
* [ ] Extended Program Check, ATC and Code Inspector have been run.
* [ ] Applicable errors and warnings are cleared or formally justified.
* [ ] Error handling, messages and logs are meaningful.
* [ ] Database access and internal-table choices are efficient and maintainable.
* [ ] Unit testing is complete and evidence is available.
* [ ] No disallowed, obsolete, sample or commented-out code remains.
* [ ] The transport content is ready for peer review.

### SAPUI5 developer checklist

* [ ] Versions and identifiers are current.
* [ ] No duplicate declarations, sample code or unexplained commented-out code remain.
* [ ] Functions and section headings are logically organised.
* [ ] Prettier has been run and ESLint passes without errors or warnings.
* [ ] CSS files required by the repository are not left empty.
* [ ] Model binding and UI events are handled in the controller as specified.
* [ ] Automated tests and /tests/ content are current.
* [ ] The related GitLab issue, feature branch and merge request are in place.

## Governance and exceptions

* Customer standards take precedence within the customer namespace.
* Where a customer standard covers only part of the development, apply this standard to the remaining areas.
* Changes to the coding standard require approval from the senior technical team member on the project.
* Exceptions must be explicit, technically justified and documented in the specification, code review or project record as appropriate.
* A reviewer must not approve a change solely because automated checks pass; implementation correctness, maintainability and operational behaviour still require manual review.