Primeros pasos con abaplint | Blogs de SAP

DevOps para SAP está teniendo un momento. Cada vez más organizaciones de élite y desarrolladores destacados están aprovechando los beneficios que se derivan de aplicar los principios de desarrollo modernos al desarrollo ABAP. El viaje no es fácil, pero vale la pena, y dar un paso a la vez lo hace mucho más fácil. Un pequeño paso es comenzar con la implementación de un linter en su código ABAP.

¿Qué es un linter?

Un linter es una herramienta que analiza el código fuente para identificar posibles errores, fallas o problemas que se pueden detectar a través del análisis estático.

Cuando escribes un programa, escribes un montón de instrucciones para que las siga la computadora. Estas instrucciones deben escribirse de cierta manera, o el programa podría no funcionar como se esperaba. El análisis estático verifica las instrucciones para asegurarse de que estén escritas correctamente y sigan las reglas.

Las herramientas de Linter son ayudantes robóticos, típicamente diseñados para analizar el código fuente contra un conjunto de reglas o pautas predefinidas específicas para el lenguaje y el contexto de desarrollo. Por ejemplo, un linter para ABAP podría buscar errores comunes como variables no utilizadas o períodos faltantes. Al encontrar y corregir estos errores temprano, el programador puede asegurarse de que el programa funcione como se supone que debe hacerlo cuando se ejecuta.

abaplint es un linter potente y flexible para SAP. fue creado por Lars Hvam, el pionero del movimiento ABAP de código abierto. Así que sí, abaplint también es de código abierto.

¿Por qué lo necesito?

Si su organización se preocupa por brindar una experiencia de usuario superior a sus clientes, necesita un software confiable. El software confiable requiere código mantenible y de alta calidad, y abaplint (o cualquier linter ABAP) lo ayuda a lograrlo.

1. Calidad de código mejorada: abaplint puede ayudar a identificar posibles problemas y violaciones de las mejores prácticas en su código ABAP, lo que le permite abordar estos problemas y mejorar la calidad general de su código.
2. Consistencia: abaplint puede ayudar a garantizar que su código siga un estilo y una estructura consistentes, mejorando la legibilidad y la capacidad de mantenimiento.
3. Personalización: abaplint es altamente personalizable, lo que le permite configurar la herramienta para satisfacer sus necesidades y requisitos específicos.
4. Integración: abaplint se puede integrar en su flujo de trabajo de desarrollo, lo que le permite verificar automáticamente su código en busca de posibles problemas como parte de sus procesos de prueba.

¿Quién lo usa?

Los linters prevalecen fuera del desarrollo de SAP. Dentro del desarrollo de SAP, abaplint es utilizado por equipos de alto rendimiento que necesitan aprovechar el poder de la automatización para ser más eficientes.

¿Cuándo es el mejor momento para implementarlo?

Ahora. 🙂

Dado que las reglas son configurables, puede comenzar rápidamente con un conjunto de reglas pequeño y continuar expandiendo las reglas según sea necesario.

¿Cómo empiezo?

abaplint se ejecuta comprobando el código ABAP que se serializa mediante abapGit. Para esta guía de inicio, solo demostraré cómo ejecutar abaplint en GitHub (Configuración de integración continua). Para obtener detalles sobre otras configuraciones, consulte la abaplint en GitHub.

Si su código aún no está en GitHub, necesita abapGit. Hay varios recursos sobre cómo hacer esto, Documentación – abapGit o Vídeo SAP – Instalar abapGit en 2022

Una vez que su código esté en GitHub, debe hacer tres cosas.

1. Agregue la configuración del flujo de trabajo, abaplint.yml
2. Actualice el repositorio «Permisos de flujo de trabajo»
3. Agregar un archivo de configuración de abaplint abaplint.jsonc

1. Configuración del flujo de trabajo

Crear un archivo en la siguiente ruta your-repository/.github/workflows/abaplint.yml

Agregue los contenidos a continuación.

name: abaplint
     
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: abaplint
      uses: abaplint/actions-abaplint@main
      # GITHUB_TOKEN in forked repositories is read-only
      # https://help.github.com/en/actions/reference/events-that-trigger-workflows#pull-request-event-pull_request
      if: ${{ github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository }}
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Configuraciones alternativas

Para obtener más información sobre la configuración, consulte el abaplint documentación para Integración Continua.

Alternativamente, también puede configurar fácilmente su flujo de trabajo suscribiéndose a la aplicación en GitHub Marketplace https://github.com/marketplace/abaplint.

2. Permisos de flujo de trabajo

Desde la página del repositorio, vaya a Configuración, Acciones, General.

Actualice los permisos del flujo de trabajo a «permisos de lectura y escritura»

3. Archivo de configuración

Agreguemos la configuración de abaplint. A continuación se muestra un archivo de ejemplo.

{
  "global": {
    "files": "/src/**/*.*"
  },
  "dependencies": [
    {
      "url": "https://github.com/abaplint/deps",
      "folder": "/deps",
      "files": "/src/**/*.*"
    }
  ],
  "syntax": {
    "version": "v702",
    "errorNamespace": "^(Z|Y|LCL_|TY_|LIF_)"
  },
  "rules": {
    "exporting": true,
    "local_class_naming": {
      "exclude": [],
      "severity": "Error",
      "patternKind": "required",
      "ignoreNames": [],
      "ignorePatterns": [],
      "local": "^LCL_.+$",
      "exception": "^LCX_.+$",
      "test": "^LTCL_.+$"
    },
    "method_parameter_names": {
      "exclude": [],
      "severity": "Error",
      "patternKind": "required",
      "ignoreNames": [],
      "ignorePatterns": [],
      "ignoreExceptions": true,
      "importing": "^I._.+$",
      "returning": "^R._.+$",
      "changing": "^C._.+$",
      "exporting": "^E._.+$"
    },
    "object_naming": {
      "exclude": [],
      "severity": "Error",
      "patternKind": "required",
      "ignoreNames": [],
      "ignorePatterns": [],
      "clas": "^ZC(L|X)",
      "intf": "^ZIF",
      "prog": "^Z",
      "fugr": "^Z",
      "tabl": "^Z",
      "ttyp": "^Z",
      "dtel": "^Z",
      "doma": "^Z",
      "msag": "^Z",
      "tran": "^Z",
      "enqu": "^EZ",
      "auth": "^Z",
      "pinf": "^Z",
      "idoc": "^Z",
      "xslt": "^Z",
      "ssfo": "^Z",
      "ssst": "^Z",
      "shlp": "^Z"
    },
    "selection_screen_naming": {
      "exclude": [],
      "severity": "Error",
      "patternKind": "required",
      "ignoreNames": [],
      "ignorePatterns": [],
      "parameter": "^P_.+$",
      "selectOption": "^S_.+$",
      "screenElement": "^SC_.+$"
    },
    "types_naming": {
      "exclude": [],
      "severity": "Error",
      "pattern": "^TY_.+$"
    },
    "unused_variables": true
  }
}

• La propiedad «global» contiene una propiedad de «archivos» que especifica el directorio ("/src/**/*.*") que contiene su código SAP.
• La propiedad «dependencies» contiene una matriz de objetos que especifican las dependencias externas que requiere abaplint.
• La propiedad «syntax» contiene una propiedad «version» que especifica la versión SAP_BASIS de la sintaxis que debe usar abaplint, y una propiedad «errorNamespace» especifica una expresión regular para qué objetos verificar.
• La propiedad «reglas» contiene un conjunto de pares clave-valor que especifican varias reglas que debe aplicar abaplint. Cada clave representa un nombre de regla y el valor define si la regla debe habilitarse.

Me centraré en la propiedad de las reglas en esta publicación. abaplint tiene más de 150 reglas que puedes habilitar. Si no incluye una regla en su configuración, está deshabilitada. Para ver todas las reglas, visite https://rules.abaplint.org.

Considere la primera regla en el abaplint.jsonc archivo de arriba.

Regla: exporting

Descripción:Detecta declaraciones de EXPORTACIÓN que se pueden omitir.

Ejemplos:

* Bad example
call_method( EXPORTING foo = bar ).

* Good example
call_method( foo = bar ).

Puede ver cómo esta verificación es útil para mantener su código limpio y evitar una sintaxis innecesariamente larga. Esto también se ajusta a la recomendación de EXPORTACIÓN en el Guía de estilo SAP Clean ABAP.

Echemos un vistazo a cómo se vería cuando se activa abaplint.

Puedo actualizar mi código para seguir la Guía de estilo Clean ABAP.

lo_exporting_parameter->get_parameter( iv_input="Hello World" ).

Después de confirmar el cambio, abaplint se vuelve a activar automáticamente. Esta vez, todo se ve bien.

Me gusta comenzar con un pequeño conjunto de reglas y agregar más continuamente. Lo más probable es que si no ha utilizado un linter, su código necesitará muchos cambios. Si aplica muchas reglas desde el principio, puede ser abrumador tratar de arreglar su código. Una vez que todos los controles pasan con un conjunto de reglas determinado, le recomiendo que continúe agregando reglas.

Próximos pasos

Deja un comentario si este tema es interesante o si quieres ver escenarios más avanzados.

¿Estás usando un linter? Si es así, deja algunos detalles de tu experiencia en los comentarios.

Créditos fotográficos: Duncan Meyer en Unsplash