Uno de los problemas más comunes en ABAP (y en cualquier lenguaje) es el exceso de indentación.
Empiezas con un IF, luego otro dentro, luego otro más… y acabas con código que parece una escalera. Difícil de leer, difícil de mantener, fácil de equivocarse.
Ejemplo típico:
IF lv_material IS NOT INITIAL.
IF lv_cantidad > 0.
IF lv_cliente IS NOT INITIAL.
" Código principal
ENDIF.
ENDIF.
ENDIF.
Esto funciona. Pero el problema es que la lógica importante queda enterrada dentro de varios niveles de indentación.
¿Qué es Happy Indentation?
No es una regla oficial ni una sintaxis especial. Es un estilo de programación que persigue un objetivo simple: validar los casos incorrectos al principio y salir rápido, para que el flujo principal quede plano y sin anidaciones innecesarias.
En vez de meter toda la lógica dentro de un ELSE, sales antes y mantienes el flujo principal limpio y lo más plano posible
Las posibles opciones en ABAP son:
CHECK (para condiciones simples)
CHECK es ideal para validaciones simples.
CHECK lv_material IS NOT INITIAL.
" Código principal
Si alguna condición falla, la ejecución se detiene ahí. El código principal solo se ejecuta si todo está bien.
⚠️ CHECK funciona dentro de LOOPs y métodos. En un programa normal, si falla, termina el bloque actual (no todo el programa).EE
El resultado es un código mucho más limpio y sin nesting innecesario.
RETURN (dentro de métodos o funciones)
RETURN se usa sobre todo en métodos..Ppuedes hacerlo así:
METHOD procesar_pedido.
IF lv_material IS INITIAL.
MESSAGE 'Material obligatorio' TYPE 'E'.
RETURN.
ENDIF.
IF lv_cantidad EQ 0.
MESSAGE 'Cantidad debe ser mayor a cero' TYPE 'E'.
RETURN.
ENDIF.
" Código principal (sin anidación)
ENDMETHOD.
De esta forma las validaciones quedan arriba y la lógica principal queda limpia y alineada.
EXIT (dentro de LOOPs)
EXIT suele utilizarse dentro de loops.
LOOP AT lt_materiales INTO ls_mat.
IF ls_mat-matnr IS INITIAL.
EXIT. " Sale del LOOP
ENDIF.
" Procesar material
ENDLOOP.
La idea es exactamente la misma cortar pronto y evitar profundidad innecesaria, para que el código principal intente no moverse de la primera columna.
Por qué esto mejora el código
| Beneficio | Explicación |
|---|---|
| Menos indentación | El código no se desplaza hacia la derecha. Es más fácil de leer de un vistazo. |
| El flujo principal destaca | La lógica importante no está escondida dentro de tres IF. |
| Menos carga cognitiva | Cada nivel de anidación añade complejidad mental. Menos niveles = menos esfuerzo para entender. |
| Errores más visibles | Las validaciones están al principio, agrupadas y visibles. No «perdidas» dentro del código. |
Happy indentation es una forma de escribir código más limpio, más plano y más fácil de mantener. No significa usar CHECK, RETURN y EXIT sin criterio. Significa no esconder la lógica principal dentro de tres IF seguidos. La idea clave es simple:
Porque normalmente:
menos indentación = código más legible.




