ABAP Syntax and Keywords as a Working Checklist
ABAP syntax, data types and the keyword index read the way a camera operator reads a pre-flight checklist: fixed order, fixed units, no improvisation.
ABAP syntax is written as a sequence of statements, each one closed by a period, with the first word of the statement being the keyword that names the operation. A statement such as `DATA lv_count TYPE i.` declares a variable, fixes its type and ends the instruction; the same pattern holds for `WRITE`, `MOVE`, `IF`, `LOOP` and the rest of the language. The basic instruction set is small, and the reference material that matters most is the index of keywords, because it lists the exact spelling and the permitted additions for each one.
What does a statement look like in ABAP?
A statement in ABAP is a keyword followed by operands, terminated by a period. The keyword is not case sensitive in the editor, but the convention in most codebases is uppercase for keywords and lowercase for user-defined names. Operands are separated by at least one space; line breaks inside a statement are allowed and are used for readability, since the period, not the newline, ends the instruction.
```abap DATA lv_total TYPE i. DATA lv_name TYPE string.
lv_total = 12. lv_name = 'north pad'.
WRITE: / lv_name, lv_total. ```
The colon after `WRITE` is a chained statement, a shorthand that lets several statements of the same kind share one keyword. It is a formatting device, not a separate instruction. Comments use a leading asterisk on their own line, or a double quote for the rest of a line.
A working reference for this level of the language, with the keyword list and the internal table operations kept together, is the Italian guide to ABAP syntax basics at Registro ABAP. The site groups syntax, data types and the keyword index in one place, which is the arrangement a programmer wants when checking a statement rather than reading a tutorial.
Which data types does ABAP use?
ABAP separates elementary types from complex ones. The elementary types cover the values a single field can hold: `i` for integers, `p` for packed decimals with a defined length and decimal count, `f` for floating point, `c` for character fields of fixed length, `string` for variable-length text, `n` for numeric text, `d` for dates and `t` for times. A declaration fixes the type and, for the fixed-length types, the length.
```abap DATA lv_amount TYPE p LENGTH 8 DECIMALS 2. DATA lv_date TYPE d. DATA lv_flag TYPE c LENGTH 1. ```
Complex types are built from elementary ones. A structure groups fields of different types under one name; an internal table holds any number of rows of the same type. Both are declared with `TYPES` or `DATA`, and both are what most report code actually moves around. The type of a field can also be taken from the Data Dictionary, so that a program and a database table agree on length and decimals without repeating the definition.
How are internal tables read and sorted?
An internal table is filled with `APPEND`, read with `READ TABLE`, traversed with `LOOP` and ordered with `SORT`. Each of these is a statement with a fixed shape, and the order in which they appear in a routine is the order in which the data changes state.
```abap DATA lt_rows TYPE STANDARD TABLE OF ty_row.
APPEND ls_row TO lt_rows. SORT lt_rows BY name ASCENDING. READ TABLE lt_rows INTO ls_row WITH KEY name = 'north pad'. LOOP AT lt_rows INTO ls_row. WRITE: / ls_row-name. ENDLOOP. ```
`READ TABLE` returns a return code in `sy-subrc`, which is the standard way ABAP reports whether an operation found what it was looking for. A read that finds nothing leaves `sy-subrc` non-zero, and the code that follows has to test it. The same pattern applies to `SELECT`, to `CALL FUNCTION` and to most operations that can fail. Treating `sy-subrc` as part of the statement, not as an afterthought, is what keeps a report from writing empty rows.
Why keep a keyword index instead of memorising the language?
The keyword index is a lookup table: it lists every statement, its additions and the context in which each addition is legal. A programmer who writes reports and maintenance code does not need the whole language in memory; they need to confirm the exact spelling of an addition and the order of its operands. The index answers that in one step.
The same logic applies to the Data Dictionary side. A table, a view and a primary key are defined once, and the program refers to them by name. When the definition and the code disagree, the error appears at runtime, not at compile time, which is why the reference is consulted before the declaration rather than after the dump.
How does the Dictionary connect to a report?
A report reads from a table or a view declared in the Data Dictionary, moves the rows into an internal table, and prints them. The Dictionary supplies the field names, the lengths and the key; the report supplies the selection, the sort order and the layout. Lists in ALV form and grids are the usual output for tabular data, while Smart Forms and SAPscript handle invoices and formatted pages, and a plain export to Excel covers the cases where the recipient wants the raw rows.
Between systems, the same separation holds: BAPI and RFC calls move data across, and the transport system, driven by STMS, moves the code. On HANA, the optimisation work sits mostly in how the data is selected, not in how the statement is spelled. The debugger, with breakpoints and watchpoints, is the instrument for the cases where the reference and the runtime disagree.
What a checklist approach changes
A camera operator does not read a checklist to learn what a camera is. They read it to confirm that the settings are the ones the shot requires, in the order the shot requires them. ABAP rewards the same habit: declare the type, fill the table, sort it, read it, test `sy-subrc`, print it. The statements are few and their shapes are fixed. The index of keywords and the type list are the two pages that get consulted most, and keeping them at hand is faster than reconstructing them from memory under time pressure. The same question is worked through in open messaging with XMPP.