Llevo desde los 18 años programando, y empecé por curiosidad y en casa. Es algo que se me da bien, me gusta y me genera satisfacción «crear» algo donde no lo había. Mi perfil profesional actual es bastante amplio, pero nunca quiero dejar ese aspecto de mi día día. Es algo que me llena, que me alegra…. hasta que veo algunas masacres de código que hay por el mundo, que me entran ganas de matar.

Hoy voy a hablar de la calidad del código, no solo en su efectividad, también en su eficiencia, su facilidad de lectura y mantenimiento. A muchos les parecerá una tontería, algo sin importancia, pero un buen código simplifica mucho el mantenimiento, la reutilización, la lectura y documentación.

CleanABAP

Existe un proyecto en GitHub llamado Clean ABAP donde la comunidad de desarrolladores ABAP han sacado una guía de estilo de desarrollo ABAP con las mejores prácticas. Además está en varios idiomas, incluido el Español lo puedes ver aquí.

GitHub – CleanABAP

Y claro, yo iba a escribir mi libro de buenas prácticas desde mi punto de vista. Cosa que he hecho en algún proyecto al ver los desastres que la gente generaba en el sistema. Pero, al ver que ya había un consenso entre desarrolladores ABAP, y que no estaba solo en esto, pues mejor. Lo que voy a hacer es extraer de la guía de estilo CleanABAP aquellas recomendaciones que vea más necesarias. En la guía de estilo (lectura recomendadísima), se dividen las recomendaciones por áreas, vamos a respetarlas por si quieres ir a ver la fuente.

NOTA: Si estás viendo esto desde un móvil o tablet mejor en horizontal, las líneas de código se te van a cortar y hay cosas que no entenderás. No obstante, es preferible que lo leas desde el PC.

Formato

Optimiza para lectura, no para escritura

Siempre escribe pensando en la legibilidad del código, no en lo rápido que puedas escribirlo.

" Ejemplo Incorrecto 
DO 10 TIMES. lv_value = lv_value + 1. ENDDO.

" Ejemplo Correcto
DO 10 TIMES.
  lv_value = lv_value + 1.
ENDDO.

Usa el Pretty Printer antes de activar

Bueno, yo con esta ya si que me corto las venas. Es un &#+%€ botón, pulsar un botón y te hace gran parte del trabajo.

Usa el Pretty Printer.

En serio. Usa el Pretty Printer.

Usa la configuración de Pretty Printer de tu equipo

Enlazado con lo anterior, tampoco estamos hablando de ingeniería. Es configurar tu Pretty Printer para que actúe de la forma que se consensue en tu equipo de trabajo. Yo, personalmente me gusta así:

Y esto es por lo siguiente:

• Sangrar: Obvio, que el texto tenga sus correspondientes sangrías que te indiquen el nivel en el que estás es fundamental.
• Conversión mayúsc./minúsc.: A mi me parece muy interesante que las palabras clave sean mayúsculas para ver claramente la acción que se está realizando e identificar las sentencias ABAP de variables, parámetros y literales.

" Ejemplo sin palabras clave mayúsculas
select partner into lv_partner
               from but000
              where bu_group = lv_clientes
                and xdele = abap_false
                and type = 1.

" Ejemplo con palabras clave mayúsculas
SELECT partner INTO lv_partner
               FROM but000
              WHERE bu_group = lv_clientes
                AND xdele = abap_false
                AND type = 1.

Por favor, usa el Pretty Printer.

No más de una sentencia por línea de código

Cada línea de código debe contener solo una sentencia, evitando mezclar varias operaciones en una sola línea.

Para mi esto es especial para los IFs con múltiples condiciones. Todo de seguido no se ve claramente.

" Ejemplo Incorrecto 
IF lv_total > 100 And lv_is_customer = 'X' AND lv_country = 'ES'. lv_discount = lv_total * 0.1. ELSE. lv_discount = 0. ENDIF.

" Ejemplo Correcto 
IF lv_total       > 100 AND
   lv_is_customer = 'X' AND 
   lv_country     = 'ES'.
  lv_discount = lv_total * 0.1.
ELSE.
  lv_discount = 0.
ENDIF.

Aquí la posición de los AND y OR ya es manía personal, hay quien los pone al principio, a mi me gusta ponerlo al final y alinear las variables, los operadores y los AND/OR.

Mantén una longitud de línea razonable

Si la línea de código es demasiado larga, divídela en varias líneas para que sea más fácil de leer y seguir.

" Ejemplo Incorrecto
SELECT carrid connid fldate FROM sflight INTO TABLE lt_sflight WHERE carrid = 'LH' AND connid = '0400' AND fldate = '20231010'.

" Ejemplo Correcto 
SELECT carrid
       connid
       fldate INTO TABLE lt_sflight 
                    FROM sflight
                   WHERE carrid = 'LH'
                     AND connid = '0400'
                     AND fldate = '20231010'.

Vamos, no hay color. Mi manía personal es ponerlo en ese orden (SELECT, INTO, FROM, WHERE), y alineando desde el INTO. Además con las sentencias ABAP alineadas el código tiene más aire y se lee mejor. Se identifica claramente qué se selecciona, a donde se guarda, de qué tablas y con qué condiciones.

Usa una línea en blanco para separar cosas, pero no más

Utiliza una línea en blanco para separar lógicamente secciones del código, como declaraciones de variables y bloques de código, pero evita poner líneas en blanco innecesarias.

Los bloques de sentencias han de estar separados para su entendimiento. Todo junto no se lee bien.

" Ejemplo Incorrecto
DATA: ls_order TYPE zorder,
      lv_total TYPE p DECIMALS 2,
      lv_discount TYPE p DECIMALS 2.
ls_order-order_id = 'ORD001'.
ls_order-customer_id = 'CUST001'.
ls_order-status = 'OPEN'.
lv_total = 500.
lv_discount = lv_total * 0.1.
ls_order-total_amount = lv_total.
ls_order-discount_amount = lv_discount.
INSERT zorder FROM ls_order. 


" Ejemplo Correcto 
DATA: ls_order TYPE zorder,
      lv_total TYPE p DECIMALS 2,
      lv_discount TYPE p DECIMALS 2.

ls_order-order_id    = 'ORD001'.
ls_order-customer_id = 'CUST001'.
ls_order-status      = 'OPEN'.

lv_total    = 500.
lv_discount = lv_total * 0.1.

ls_order-total_amount    = lv_total.
ls_order-discount_amount = lv_discount.

INSERT zorder FROM ls_order.

Alinea asignaciones al mismo objeto, pero no a objetos diferentes

Cuando asignas valores a varios atributos de un mismo objeto, puedes alinearlos para mejorar la legibilidad, pero evita alinear asignaciones entre diferentes objetos.

" Ejemplo Incorrecto
ls_order-order_id       = 'ORD001'.
ls_order-customer_id    = 'CUST001'.
lv_total                = 500.
ls_order-total_amount   = lv_total.
lv_discount             = lv_total * 0.1.
ls_order-discount_amount = lv_discount. 

" Ejemplo Correcto 
ls_order-order_id        = 'ORD001'.
ls_order-customer_id     = 'CUST001'.
ls_order-total_amount    = lv_total.
ls_order-discount_amount = lv_discount.

lv_total    = 500.
lv_discount = lv_total * 0.1.

Cierra paréntesis en la última línea de código

Si una operación requiere múltiples líneas, como al construir cadenas o usar condicionales, cierra los paréntesis en la última línea.

" Ejemplo Incorrecto
lo_instance->set_data(
    EXPORTING 
      iv_name = lv_name
      iv_age = lv_age
  ).

" Ejemplo Correcto
lo_instance->set_data(
    EXPORTING 
      iv_name = lv_name
      iv_age  = lv_age ).

" Cómo lo hago yo
lo_instance->set_data( EXPORTING iv_name = lv_name
                                 iv_age  = lv_age ).

Mantén los parámetros detrás de la llamada

Cuando llamas a un método o función con parámetros, organiza los parámetros en líneas separadas si la llamada es demasiado larga.

" Ejemplo Incorrecto
lo_instance->set_data( EXPORTING iv_name = lv_name iv_age = lv_age ).

" Ejemplo Correcto 
lo_instance->set_data(
  EXPORTING
    iv_name = lv_name
    iv_age  = lv_age).

" Cómo lo hago yo
lo_instance->set_data( EXPORTING iv_name = lv_name
                                 iv_age  = lv_age ).

Alinea los parámetros

Si los parámetros se colocan en varias líneas, deben estar alineados para mejorar la claridad.

" Ejemplo Incorrecto
lo_instance->set_data(
    EXPORTING 
      iv_name = lv_name
      iv_age = lv_age
      iv_address = lv_address
      iv_order_id = lv_order_id ).

" Ejemplo Correcto 
lo_instance->set_data(
    EXPORTING 
      iv_name     = lv_name
      iv_age      = lv_age
      iv_address  = lv_address
      iv_order_id = lv_order_id ).

" Cómo lo hago yo
lo_instance->set_data( EXPORTING iv_name     = lv_name
                                 iv_age      = lv_age
                                 iv_address  = lv_address
                                 iv_order_id = lv_order_id ).

Fíjate en el alineamiento de los =, hace que sepas claramente identificar parámetros de variables. Esto también lo suelo hacer los IFs con los comparadores, pero eso ya es manía personal.

" Ejemplo Incorrecto
IF lv_status EQ 'A' AND lv_subtype NE 'X' AND lv_amount GT 100.
  lv_result = 'Valid'.
ELSE.
  lv_result = 'Invalid'.
ENDIF.

" Cómo lo hago yo 
IF lv_status  EQ 'A' AND     
   lv_subtype NE 'X' AND 
   lv_amount  GT 100.
  lv_result = 'Valid'.
ELSE.
  lv_result = 'Invalid'.
ENDIF.

Nomenclatura

Usa nombres descriptivos

Los nombres de variables, clases y métodos deben ser lo suficientemente claros para que cualquier desarrollador entienda su propósito sin necesidad de contexto adicional. Por ejemplo

" Declaraciones no descriptivas
DATA: lv_amt       TYPE i,
      lt_cust      TYPE TABLE OF but000,
      lt_items_aux TYPE TABLE OF crmd_orderadm_i.

" Declaraciones con nombres descriptivos
DATA: lv_total_amount    TYPE i,
      lt_customers       TYPE TABLE OF but000,
      lt_items_completed TYPE TABLE OF items.

No cuesta nada y se lee todo mejor, eso sí, se consecuente con usar cada uno para lo que es, no vayas a meter en lt_items_completed cualquier tipo de posiciones de pedido porque te venga bien.

Usa sustantivos para las clases y verbos para los métodos

Las Clases deberían representar conceptos o entidades y, por lo tanto, se nombran como sustantivos.

" Ejemplos
order_calculator
order_utils

Los Métodos representan acciones o comportamientos, por lo que deben nombrarse con verbos.

" Ejemplo
calculate_total
get_partners
add_item
modify_status

Usa snake_case

Para mejorar la legibilidad en ABAP, se prefiere el uso de snake_case en lugar de camelCase o PascalCase en variables y métodos. El uso de snake_case es una convención ampliamente utilizada en el código ABAP debido a su compatibilidad con otras herramientas del ecosistema SAP y porque ayuda a mejorar la claridad del código, haciéndolo más legible y fácil de seguir para los desarrolladores.

" Ejemplos Incorrectos
DATA: TotalAmountDue type p decimals 2.
DATA: itemstoadd type table of items.

" Ejemplos Correctos
DATA: lv_total_amount_due TYPE p DECIMALS 2,
      lt_items_to_add TYPE TABLE OF items.

---

Constantes

Usa constantes en lugar de números mágicos

Evita usar números sin contexto directamente en el código. En su lugar, define constantes para mejorar la legibilidad.

" Ejemplo Incorrecto
IF lv_value > 42.

" Ejemplo Correcto
IF lv_value > gc_max_allowed.

Sabemos que el 42 es «El sentido de la vida, el universo y todo lo demás» pero a lo mejor en tu proceso no es el sentido de ese número. Usa constantes, puedes declararlas en un INCLUDE TOP o bien en una clase estática que aglutine varias constantes.

Prefiere clases de enumeración a interfaces de constantes

Esto lo he añadido por el punto anterior. Lo que yo suelo hacer es crear una serie de clases UTIL con métodos estáticos, con un sentido funcional cada una, y sus constantes correspondientes. Voy a poner un ejemplo:

CLASS zcl_crm_ofertas_util DEFINITION.
  PUBLIC SECTION.

    " Constantes para los estados de la oferta
    CONSTANTS:
      c_estado_abierto TYPE char10 VALUE 'E0001',
      c_estado_cerrado TYPE char10 VALUE 'E0002'.

    " Métodos estáticos
    CLASS-METHODS:
      get_datos_oferta
        IMPORTING iv_oferta_id TYPE char10
        RETURNING VALUE(rt_oferta_datos) TYPE TABLE OF zcrm_oferta.

    CLASS-METHODS:
      get_interlocutores
        IMPORTING iv_oferta_id TYPE char10
        RETURNING VALUE(rt_interlocutores) TYPE ztt_interlocutores.
ENDCLASS.

Y las constantes c_estado_abierto y c_estado_cerrado podemos usarlo en cualquier código para comprobar si un pedido tiene ese estado.

IF lv_estado_pedido EQ zcl_order_util=>c_estado_abierto.
  " Hacer cosas
ENDIF.

Variables

Prefiere declaraciones in-line que al inicio

Este apartado no estoy al 100% de acuerdo, porque soy de vieja escuela, antes de que las declaraciones In-line estuviesen disponibles y suelo hacer bastantes declaraciones al inicio. No obstante, creo que tiene bastante razón.

" Ejemplo Incorrecto
METHOD calculate_discount.
  DATA: lv_discount     TYPE p DECIMALS 2,
        lv_total_amount TYPE p DECIMALS 2,
        lt_clientes     TYPE TABLE OF but000.

  lv_total_amount = amount + tax.
  IF lv_total_amount > 100.
    lv_discount = lv_total_amount * 0.1.
  ELSE.
    lv_discount = 0.
  ENDIF.

  SELECT * INTO TABLE lt_clientes
                 FROM but000
                WHERE bu_group EQ 'Z001'.
ENDMETHOD.

" Ejemplo Correcto
METHOD calculate_discount.
  DATA(lv_total_amount) = amount + tax.

  DATA(lv_discount) = lv_total_amount * 0.1.

  IF lv_total_amount <= 100.
    lv_discount = 0.
  ELSE.

  SELECT * INTO TABLE @DATA(lt_clientes)
                 FROM but000
                WHERE bu_group EQ zcl_bp_util=>c_agrupación_cliente.
ENDMETHOD.

Lo importante es conocer las declaraciones In-line que son muy útiles y aportan claridad y limpieza al código.

No encadenes declaraciones

Cada declaración debe ocupar una línea por sí misma. Esto facilita el seguimiento de las variables.

" Ejemplo Incorrecto
DATA: lv_value TYPE i, lv_discount TYPE p, lv_total TYPE p.

" Ejemplo Correcto
DATA: lv_value    TYPE i, 
      lv_discount TYPE p, 
      lv_total    TYPE p.

A lo que yo añado lo siguiente

Usa «DATA:» y evita usar múltiples DATA

Entras en un código y te encuentras con esto

DATA lv_es_cliente TYPE bu_partner.
DATA lt_pedidos_abiertos TYPE TABLE OF zpedidos.
DATA ls_pedidos_abiertos TYPE zpedidos.
DATA lv_fecha_creacion TYPE datum.
DATA lv_sociedad TYPE werks.
DATA lt_pedidos_cerrados TYPE zpedidos.

Pero ¿Para qué ponemos tantos DATA. Si ponemos solo un DATA: el Pretty Printer se va a encargar de darle mucho aire y alinear los TYPE.

DATA: lv_es_cliente       TYPE bu_partner.
      lt_pedidos_abiertos TYPE TABLE OF zpedidos.
      ls_pedidos_abiertos TYPE zpedidos.
      lv_fecha_creacion   TYPE datum.
      lv_sociedad         TYPE werks.
      lt_pedidos_cerrados TYPE zpedidos.

Vamos. no hay color, y eso que he puesto un ejemplo con seis líneas, he llegado a ver decenas de DATA juntos. Ya sabes, usa el Pretty Printer.

Tablas

Prefiere INSERT INTO TABLE a APPEND TO

Usar INSERT INTO TABLE es más versátil y claro para la inserción de datos en tablas internas. Además el uso del APPEND da errores en las tablas de tipo SORTED y en INSERT INTO TABLE lo gestiona bien.

" Ejemplo Incorrecto
APPEND ls_cliente TO lt_clientes.

" Ejemplo Correcto
INSERT ls_cliente INTO TABLE lt_clientes.

Ocupa lo mismo y no da problemas.

Prefiere LINE_EXISTS a READ TABLE o LOOP AT

En lugar de leer tablas para verificar si una línea existe, usa la función LINE_EXISTS, que es más clara y eficiente. Esto no lo suelo usar mucho, porque soy vieja escuela, pero me parece muy interesante.

" Ejemplo Incorrecto
READ TABLE lt_table WITH KEY id = lv_id TRANSPORTING NO FIELDS.
IF sy-subrc = 0.
  WRITE: 'La línea existe'.
ELSE.
  WRITE: 'La línea no existe'.
ENDIF.

" Ejemplo Correcto
IF line_exists( lt_table[ id = lv_id ] ).
  WRITE: 'La línea existe'.
ELSE.
  WRITE: 'La línea no existe'.
ENDIF.

Strings

Usa | para construir textos

En ABAP, puedes usar | para concatenar y construir cadenas de forma más limpia que con las antiguas funciones CONCATENATE.

" Ejemplo menos eficiente
CONCATENATE lv_name
            lv_surname INTO lv_fullname.

" Ejemplo más eficiente 
lv_fullname = |{ lv_name } { lv_surname }|.

Booleanos

Usa ABAP_BOOL para booleanos

ABAP tiene un tipo de datos específico para manejar valores booleanos.

" Ejemplo Incorrecto 
DATA(lv_flag) TYPE c.

" Ejemplo Correcto 
DATA(lv_flag) TYPE abap_bool.

Usa ABAP_TRUE y ABAP_FALSE para hacer comparaciones

Utiliza estos valores predefinidos para hacer las comparaciones booleanas en lugar de ‘X’ o ‘ ‘.

" Ejemplo Incorrecto
IF lv_flag = 'X'. 

" Ejemplo Correcto 
IF lv_flag = abap_true.

Usa XSDBOOL para asignar variables booleanas

XSDBOOL convierte el resultado de una expresión lógica en un valor booleano.

" Ejemplo Incorrecto
IF lv_value > 10.
  lv_flag = abap_true. 
ENDIF. 

" Ejemplo Correcto 
lv_flag = XSDBOOL( lv_value > 10 ).

Condiciones

Considera descomponer condiciones complejas

Si una condición es demasiado larga o complicada, descomponerla en variables intermedias o métodos ayuda a mejorar la claridad.

" Ejemplo Incorrecto
IF lv_total > 100 AND 
   lv_customer_active = abap_true AND 
   lv_discount > 0 AND 
   ( lv_country = 'ES' OR 
     lv_special_customer = 'X' ).
  lv_final_price = lv_total - lv_discount.
ENDIF.

" Ejemplo Correcto 
DATA(lv_is_eligible) =  xsdbool( lv_total > 100 AND
                                 lv_customer_active = abap_true ).
DATA(lv_has_discount) =  xsdbool( lv_discount > 0 ).
DATA(lv_is_preferred_customer) = xsdbool( lv_country = 'ES' OR
                                          lv_special_customer = 'X' ).

IF lv_is_eligible           = abap_true AND
   lv_has_discount          = abap_true  AND
   lv_is_preferred_customer = abap_true.
  DATA(lv_final_price) = lv_total - lv_discount.
ENDIF.

Considera extraer condiciones complejas

Si las condiciones complejas se usan repetidamente, pueden extraerse en métodos o Performs con nombres descriptivos.

" Ejemplo Incorrecto
SELECT SINGLE descuento INTO lv_descuento 
                        FROM zdescuentos 
                       WHERE producto EQ lv_producto1. 

IF lv_descuento EQ abap_true.
  lv_precio1 = lv_precio1 * 0,75.
ENDIF. 

CLEAR lv_descuento. 

SELECT SINGLE descuento INTO lv_descuento 
                        FROM zdescuentos 
                       WHERE producto EQ lv_producto2. 

IF lv_descuento EQ abap_true.
  lv_precio2 = lv_precio2 * 0,75.
ENDIF. 


" Ejemplo Correcto
IF is_eligible_for_discount( lv_producto1 ).
  lv_precio1 = lv_precio1 * 0,75.
ENDIF. 

IF is_eligible_for_discount( lv_producto2 ).
  lv_precio2 = lv_precio2 * 0,75.
ENDIF. 

Ifs

Prefiere CASE a ELSE IF para múltiples condiciones

Si tienes múltiples ramas condicionales, un CASE es generalmente más claro y conciso.

" Ejemplo Incorrecto
IF lv_estado = c_abierto.
  ...
ELSEIF lv_value = c_en_proceso.
  ...
ELSEIF lv_value = c_cerrado. 
  ... 
ENDIF.

" Ejemplo Correcto
CASE lv_estado. 
  WHEN c_abierto. 
    ... 
  WHEN c_en_proceso. 
    ...
  WHEN c_cerrado. 
    ...
ENDCASE. 

Mantén la profundidad del anidamiento baja

Evita crear múltiples niveles de anidamiento, ya que hace el código más difícil de seguir.

" Ejemplo Incorrecto
IF lv_total > 100.
  IF lv_discount > 0.
    IF lv_customer_active = abap_true.
      lv_final_price = lv_total - lv_discount.
    ENDIF.
  ENDIF.
ENDIF.

" Ejemplo Correcto
IF lv_total > 100  AND  
   lv_discount > 0 AND 
   lv_customer_active = abap_true.
  lv_final_price = lv_total - lv_discount.
ENDIF.

Métodos

Prefiere llamadas funcionales a procedurales

Las llamadas funcionales hacen que el código sea más modular y reutilizable.

" Ejemplo Incorrecto
CALL METHOD lo_instance->set_data
  EXPORTING
    iv_name = lv_name
    iv_age  = lv_age.

" Ejemplo Correcto
lo_instance->set_data( iv_name = lv_name 
                       iv_age = lv_age ).

Omite el uso de RECEIVING

Puedes omitir estas palabras clave en las llamadas a métodos si no son necesarias para mejorar la concisión del código.

" Ejemplo Incorrecto
CALL METHOD lo_instance->get_data
  RECEIVING
    rv_result = lv_result.

" Ejemplo Correcto
lv_result = lo_instance->get_data( ).

Omite la palabra clave opcional EXPORTING

La palabra clave EXPORTING puede omitirse en llamadas a métodos para mejorar la simplicidad del código.

" Ejemplo Incorrecto
CALL METHOD lo_instance->set_data
  EXPORTING
    iv_name = lv_name
    iv_age  = lv_age.

" Ejemplo Correcto
lo_instance->set_data( iv_name = lv_name 
                       iv_age = lv_age ).

Omite el nombre del parámetro en llamadas de un solo parámetro

Cuando un método tiene un solo parámetro, no es necesario especificar su nombre.

" Ejemplo Incorrecto
lo_instance->get_name( iv_name = lv_name ).

" Ejemplo Correcto
lo_instance->get_name( lv_name ).

Haz una cosa, hazla bien, no hagas más que eso

Este es uno de los principios básicos de CleanABAP. Es mejor hacer un método que haga una cosa cada vez para que el código se pueda leer de forma sencilla y coherente. Para que el método haga una cosa nos tenemos que asegurar que:

• Tiene pocos parámetros: Un método que hace una sola cosa debería tener pocos parámetros de entrada. Tener muchos parámetros indica que el método podría estar haciendo más de una tarea
• No tiene parámetros booleanos de entrada: Los parámetros booleanos en un método pueden ser una señal de que el método realiza dos cosas: una cuando el valor es verdadero y otra cuando es falso.
• Tiene exactamente un parámetro de salida: Un método que hace una sola cosa debería tener solo un resultado. Si devuelve más de un valor, probablemente esté realizando múltiples tareas
• Es corto: Un método debe ser corto y directo. Si un método es demasiado largo, es una señal de que está realizando múltiples tareas.
• Desciende un nivel de abstracción: Un buen método debe enfocarse en un solo nivel de abstracción. No debe mezclar operaciones de bajo nivel (como acceso a base de datos) con operaciones de alto nivel (como lógica de negocio)
• Lanza un solo tipo de excepción: Si un método lanza múltiples tipos de excepciones, es probable que esté haciendo más de una cosa
• No puedes extraer más métodos de él con un significado claro: Si no puedes dividir un método en varios métodos más pequeños que tengan un propósito claro y diferenciado, entonces probablemente el método está bien estructurado.
• No puedes agrupar sus sentencias en secciones lógicas: Si las sentencias de un método se pueden agrupar en diferentes secciones, es probable que el método esté realizando múltiples tareas.

Mensajes

Haz que los mensajes sean fáciles de encontrar

Para hacer los mensajes fáciles de encontrar en una búsqueda desde la transacción SE91. Realmente yo usaba la sentencia incorrecta, pero la recomendación es no usar eso.

" Ejemplo Incorrecto
IF 1 = 2. MESSAGE e001(ad). ENDIF.

" Ejemplo Correcto 
MESSAGE e001(ad) INTO DATA(message).

Comentarios

Exprésate en código, no en comentarios

El código bien escrito debe ser lo suficientemente claro para no requerir comentarios excesivos.

" Ejemplo Incorrecto
" Calcula el total con el descuento
lv_total = lv_total - lv_discount.

" Ejemplo Correcto
lv_total_with_discount = lv_total - lv_discount. 

Usa nombres descriptivos en lugar de comentarios, ya que esto hace el código más autoexplicativo.

Los comentarios no son excusa para nombrar mal objetos

Los nombres de variables y objetos deben ser claros y descriptivos por sí mismos, sin depender de comentarios para su explicación.

" Ejemplo Incorrecto
" Cantidad Total
DATA: lv_tot_amnt TYPE i.

" Ejemplo Correcto
DATA: lv_total_amount TYPE i.

El nombre de la variable debe ser suficientemente descriptivo para evitar depender de comentarios innecesarios.

Usa métodos en lugar de comentarios para segmentar tu código

Es más eficiente y claro usar métodos con nombres descriptivos para organizar las diferentes tareas dentro del código. Esto mejora la legibilidad y el mantenimiento del código, además de seguir el principio de hacer una sola cosa en cada método.

Los comentarios pueden volverse obsoletos o estar mal escritos, lo que puede generar confusión. Sin embargo, los métodos con nombres claros y bien definidos hacen que el propósito de cada sección sea evidente, eliminando la necesidad de comentarios explicativos.

" Ejemplo Incorrecto
METHOD process_order.
  " Validación del cliente
  IF lv_customer_id IS INITIAL.
    RETURN.
  ENDIF.

  " Calcular el total
  lv_total = calculate_total( lt_items ).

  " Aplicar el descuento
  IF lv_discount > 0.
    lv_total = lv_total - lv_discount.
  ENDIF.

  " Guardar el pedido en la base de datos
  save_order( lv_order_id ).
ENDMETHOD.

" Ejemplo Correcto 
METHOD process_order.
  validate_customer( lv_customer_id ).
  calculate_total( lt_items, lv_total ).
  apply_discount( lv_total, lv_discount ).
  save_order( lv_order_id ).
ENDMETHOD.

METHOD validate_customer.
  IF iv_customer_id IS INITIAL.
    RETURN.
  ENDIF.
ENDMETHOD.

METHOD calculate_total.
  rv_total = calculate_total( it_items ).
ENDMETHOD.

METHOD apply_discount.
  IF iv_discount > 0.
    rv_total = iv_total - iv_discount.
  ENDIF.
ENDMETHOD.

METHOD save_order.
  INSERT INTO zorders VALUES iv_order_id.
ENDMETHOD.

El diseño va en los documentos de diseño, no en el código

Evita incluir detalles de diseño en el código, ya que esto pertenece a la documentación externa. El diseño debe documentarse fuera del código para evitar que el código se vuelva innecesariamente complicado de leer.

" Ejemplo Incorrecto
" Este método sirve para crear pedidos de venta con los datos de
" entrada de cliente, datos organizativos, productos y precios.
" Los tipos de posición se calcularán en base al tipo de cliente y el 
" tipo de pedido que se quiere crear.
" Para eso se llamará a la tabla ZTB_TIPO_POS y se recuperarán los
" tipos de posición.
" El estado del pedido será siempre "Abierto"
METHOD crear_pedido_ventas.

Nadie se lee esto, además puede quedar fácilmente obsoleto al cambiar el contenido del método. Si el código se entiende, no hace falta hacer explicaciones de más.

Usa » para comentar, no *

Es preferible usar » para líneas de comentario porque se identan automáticamente al nivel donde aplican al usar Pretty Printer.

" Ejemplo Incorrecto
CASE lv_estado. 
  WHEN c_abierto. 
* Comentario en abierto 

  WHEN c_en_proceso. 
* Comentario en proceso 

  WHEN c_cerrado. 
* Comentario en cerrado

ENDCASE. 

" Ejemplo Correcto
CASE lv_estado. 
  WHEN c_abierto. 
    " Comentario en abierto 

  WHEN c_en_proceso. 
    " Comentario en proceso 

  WHEN c_cerrado. 
    " Comentario en cerrado

ENDCASE. 

Borra el código en lugar de comentarlo

El código obsoleto debe ser eliminado en lugar de ser comentado para evitar confusión. Para algo está la gestión de versiones, el código que pasa por muchas manos y correcciones se vuelve imposible de leer.

" Ejemplo Incorrecto
" lv_total = lv_total * 0,80 
" lv_total = lv_total * 0,75
lv_total = lv_total * 0,70

" Ejemplo Correcto
lv_total = lv_total * 0,70

No agregues prototipos ni comentarios de fin de métodos (INTERESANTE)

Los comentarios estándar de la firma de métodos o performs no aportan valor y generan ruido en el código. Estos comentarios pueden haber tenido sentido décadas atrás, cuando los entornos de desarrollo eran limitados, pero en los entornos modernos de ABAP (SE24, SE80, ABAP Development Tools en Eclipse), ya no son necesarios, porque la firma del método está fácilmente accesible con herramientas integradas.

" Ejemplo Incorrecto
*&---------------------------------------------------------------------*
*&      Form  CHECK_ORDER
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_LV_ABAP_BOOL  text
*      -->P_LV_COUNTRY  text
*      -->P_LV_CUSTOMER_ACTIVE  text
*      -->P_LV_HAS_DISCOUNT  text
*      <--P_LV_TOTAL  text
*      <--P_LV_SPECIAL_CUSTOMER  text
*----------------------------------------------------------------------
FORM check_order  USING    p_lv_abap_bool
                           p_lv_country
                           p_lv_customer_active
                           p_lv_has_discount
                  CHANGING p_lv_total
                           p_lv_special_customer.

" Ejemplo Correcto 
FORM check_order  USING    p_lv_abap_bool
                           p_lv_country
                           p_lv_customer_active
                           p_lv_has_discount
                  CHANGING p_lv_total
                           p_lv_special_customer.

---

En Conclusión

Me ha quedado algo largo, y eso que he hecho una selección de las recomendaciones que me parecen más interesantes. A pesar de eso, además yo tengo alguna manía más que realizo en mi día a día (no voy a añadir más leña). En entradas posteriores seguiremos hablando de esto pero desde un punto de vista de comprobar la calidad del código existente.

Por último, si solo me tuviese que quedar un un básico, diría:

USA EL PRETTY PRINTER