Untyped Declarations

An LLM trained mostly on Python and JavaScript writes DATA lv_x. and moves on, because in those languages a variable does not need a declared type. ABAP accepts that line — and gives you something you almost certainly did not want.

Detected as: llm-dynamic-typing · severity warning

Declaration without explicit type

What ABAP does with an untyped DATA

DATA lv_x. is legal. It does not mean "any type" — it is shorthand for TYPE c LENGTH 1. A single character. Assign 42 to it and you keep the 4. Assign 'Hello' and you keep the H. Nothing raises an exception; the value is simply truncated.

" What the AI wrote
DATA lv_total.
lv_total = 150.
WRITE lv_total.        " prints 1 — not 150

" What it meant
DATA lv_total TYPE i.
lv_total = 150.
WRITE lv_total.        " prints 150

This is the worst kind of bug: it compiles, it runs, and it produces a plausible wrong answer. A truncated c LENGTH 1 total looks like a data problem, not a declaration problem, so it is easy to spend an afternoon looking in the wrong place.

The same mistake with field symbols

FIELD-SYMBOLS <fs> TYPE any. is the field-symbol version. It is occasionally the right tool — genuinely generic code does need it — but as a default it turns compile-time errors into runtime ones, and the compiler can no longer help you.

" Generic: mistakes surface at runtime, if at all
FIELD-SYMBOLS <ls_row> TYPE any.

" Typed: the compiler checks every field access
FIELD-SYMBOLS <ls_row> TYPE ty_employee.

" Best where possible — inline, type inferred from the table
LOOP AT lt_employees ASSIGNING FIELD-SYMBOL(<ls_row>).
  WRITE / <ls_row>-name.
ENDLOOP.

Inline declarations are not untyped

Worth being clear, because it looks similar: DATA(lv_x) = ... has no TYPE either, and it is perfectly good ABAP. The difference is that the type is inferred from the right-hand side at compile time, not left unspecified. Modern ABAP prefers it.

DATA(lv_count) = LINES( lt_employees ).   " typed i, inferred
DATA(lv_name)  = |Alice|.                 " typed string, inferred
DATA lv_bad.                              " c LENGTH 1 — almost never intended

So the rule is not "always write TYPE". It is "never leave the type to chance".

How to fix it

Give every DATA an explicit TYPE, or use inline DATA(...) so the type is inferred.
Pick the type deliberately: i for counters, p LENGTH n DECIMALS m for money, string for genuinely variable text, char40 and friends for fixed fields.
Prefer TYPE REF TO <class> over TYPE REF TO object.
Reserve TYPE any for code that is deliberately generic — and say why in a comment.

Run the typed version →

Or paste your AI-generated code into the AI Validator to have this checked automatically.