Guía de nomenclatura en ABAP: convenciones semánticas

Cómo nombrar métodos, booleanos y lógica de negocio en ABAP.

Nombrar bien la lógica en ABAP es una de las diferencias más claras entre un código difícil de mantener y uno fácil de entender incluso años después.

En esta guía nos centramos en convenciones semánticas, es decir, en cómo nombrar correctamente métodos, booleanos, validaciones, excepciones y lógica de negocio, especialmente en ABAP orientado a objetos.

El objetivo es simple:
👉 que leyendo un nombre sepas qué hace, qué devuelve y qué impacto tiene.

Principios generales para nombrar lógica ABAP

Estas reglas aplican a todo lo que representa comportamiento, no solo a métodos:

Empieza siempre por un verbo o una pregunta
Usa inglés y snake_case
Un nombre debe explicar qué hace y qué impacto tiene
Evita palabras genéricas (process, handle, execute)
Mantén consistencia en todo el proyecto

Métodos: la unidad principal de la lógica

La forma recomendada para nombrar métodos es: verbo + objeto + contexto (si es necesario)

Ejemplos:

Correcto	Incorrecto
`get_customer_data`	`get_data`
`check_user_authorization`	`auth_check`
`calculate_total_amount`	`calc_total`
`read_orders_from_db`	`read_db`

Tipos de métodos y cómo nombrarlos

Tipo de método	Uso principal	Ejemplos
GET	Obtener datos sin modificar estado	`get_status`, `get_order_list`
SET	Asignar o modificar atributos	`set_status`, `set_defaults`
CHECK / VALIDATE	Comprobar reglas de negocio	`check_authorization`, `validate_input_data`
CALCULATE	Cálculos de negocio o matemáticos	`calculate_price`, `calculate_tax`
READ / LOAD	Acceso a BD o datos externos	`read_customer_from_db`, `load_master_data`
CREATE / BUILD	Crear objetos o resultados	`create_order`, `build_response`

Métodos de negocio vs métodos técnicos

Tipo	Descripción	Ejemplos	Visibilidad
Negocio	Representan acciones reales	`approve_order`, `post_invoice`	PUBLIC
Técnicos	Soporte interno	`map_data`, `convert_currency`	PRIVATE

Booleanos y flags: lógica condicional clara

Los métodos booleanos deben leerse como preguntas.

Prefijo	Uso	Ejemplos
`is_`	Estado	`is_valid`, `is_active`
`has_`	Posesión	`has_authorization`
`can_`	Permiso	`can_be_deleted`
`exists_`	Existencia	`exists_customer`

❌ Evita nombres como check_flag, validate_ok, status_check.

Validaciones y control de errores

Diferencia clave:

Tipo	Qué hace	Convención
Validación lógica	Devuelve boolean	`is_valid_order`
Validación crítica	Lanza excepción	`validate_order_data`

👉 Si el sistema no puede continuar, usa excepción, no booleano.

Métodos que lanzan excepciones

Si un método puede romper el flujo, su nombre debe sugerirlo.

Método	Comportamiento
`check_authorization`	Lanza excepción si falla
`validate_order_data`	Valida y aborta si es inválido
`ensure_consistency`	Garantiza reglas críticas

👉 Usa excepciones para errores críticos y booleanos solo para lógica condicional.

Excepciones: que el nombre explique el problema

Elemento	Convención	Ejemplo
Clase de excepción	`ZCX_*`	`ZCX_INVALID_STATUS`
Texto claro	Frase explícita	“Order status is invalid”

Evita excepciones genéricas como ZCX_ERROR.

Métodos estáticos

Se usan para lógica reutilizable que no depende del estado del objeto.