BC Way - Common Mistakes in AL Development (and How to Avoid Them)

Introducción

Todos hemos escrito código del que luego nos hemos arrepentido.

Ya sea por las prisas, porque "esto solo es una prueba" o porque pensamos que "ya lo arreglaré después". El problema es que ese después muchas veces nunca llega.

La buena noticia es que hoy tenemos herramientas que pueden ayudarnos a detectar muchos de estos problemas incluso antes de hacer el commit. Con la llegada del desarrollo asistido por IA y agentes, cada vez es más importante darle al agente un entorno donde sea difícil equivocarse.

En este artículo repasamos algunos de los errores más habituales en AL y cómo distintas herramientas pueden ayudarnos a evitarlos.

---

1. "Si compila, vale"... ¿Seguro?

Uno de los errores más habituales es pensar que una funcionalidad está lista simplemente porque compila.

Compilar únicamente significa que el código es válido para el compilador. No dice nada sobre:

• Calidad
• Mantenibilidad
• Rendimiento
• Buenas prácticas
• Consistencia

Aquí es donde entran en juego los ALCops.

Qué aportan los AL Cops

Los distintos CodeCops analizan el código buscando patrones problemáticos como:

• Variables sin usar
• Código muerto
• Procedimientos demasiado largos
• Naming inconsistente
• Posibles problemas de rendimiento
• Uso de APIs obsoletas

No sustituyen al desarrollador de ninguna manera, simplemente actúan como un compañero revisando continuamente el código y mostrando avisos en la pantalla de errores.

Activar los AL Cops en Visual Studio Code

En VS Code los analizadores se configuran normalmente en .vscode/settings.json:

{
  "al.enableCodeAnalysis": true,
  "al.codeAnalyzers": [
    "${CodeCop}",
    "${UICop}",
    "${PerTenantExtensionCop}",
    "${AppSourceCop}"
  ]
}

Con esto, VS Code empieza a marcar avisos, errores y recomendaciones directamente mientras escribimos AL.

También podemos usar un ruleset propio:

{
  "al.enableCodeAnalysis": true,
  "al.codeAnalyzers": [
    "${CodeCop}",
    "${UICop}",
    "${PerTenantExtensionCop}",
    "${AppSourceCop}"
  ],
  "al.ruleSetPath": "ruleset.json"
}

Ejemplo básico de ruleset.json:

{
  "name": "BC Way Ruleset",
  "description": "Reglas base para desarrollo AL",
  "rules": [
    {
      "id": "AA0008",
      "action": "Warning"
    },
    {
      "id": "AA0137",
      "action": "Error"
    }
  ]
}

Microsoft documenta cuatro analizadores principales incluidos con la extensión AL de VS Code: CodeCop, UICop, PerTenantExtensionCop y AppSourceCop.

Qué es cada AL Cop

CodeCop

Es el policía de estilo y buenas prácticas generales.

Sirve para detectar cosas como:

• naming raro
• formato inconsistente
• variables mal nombradas
• código poco legible
• patrones que no siguen las guías oficiales de AL

Es el que deberíamos activar casi siempre, incluso en proyectos internos. Microsoft lo define como el analizador que aplica las guías oficiales de AL.

UICop

Es el policía de la interfaz.

Revisa cosas relacionadas con páginas, acciones y experiencia de usuario en el cliente web.

Ayuda a detectar problemas como:

• acciones sin imagen
• propiedades de UI mal definidas
• inconsistencias en páginas
• personalizaciones que pueden afectar la experiencia del usuario

Muy útil cuando tocamos page, pageextension, actions, groups, factboxes, etc.

PerTenantExtensionCop

Es el policía para extensiones PTE.

Sirve para extensiones que se instalan directamente en un tenant concreto, no necesariamente publicadas en AppSource.

Detecta reglas que una PTE debe respetar, por ejemplo validaciones de objetos, propiedades obligatorias y restricciones específicas para ese tipo de despliegue.

AppSourceCop

Es el policía más estricto si queremos publicar en Microsoft Marketplace / AppSource.

Revisa compatibilidad, breaking changes, extensibilidad, upgrade y requisitos que Microsoft exige para publicar una app.

Es especialmente importante si estamos desarrollando una app ISV o algo que pueda acabar en AppSource. Microsoft lo define como el analizador para extensiones que se publicarán en Marketplace.

Recomendación BC Way

Para mí, una base sana sería:

{
  "al.enableCodeAnalysis": true,
  "al.codeAnalyzers": [
    "${CodeCop}",
    "${UICop}",
    "${PerTenantExtensionCop}"
  ],
  "al.ruleSetPath": "ruleset.json"
}

Y si el proyecto es ISV/AppSource:

{
  "al.enableCodeAnalysis": true,
  "al.codeAnalyzers": [
    "${CodeCop}",
    "${UICop}",
    "${AppSourceCop}"
  ],
  "al.ruleSetPath": "ruleset.json"
}

La idea no es que los Cops molesten. La idea es que nos avisen antes de subir basura al repo.

Y si todo esto te parece poco puedes instalarte AL Cops, una extensión Open-Source con multiples cops personalizados, aquí tienes los enlaces: 

ALCops - Visual Studio Marketplace

ALCops 

---

2. "La IA ya me escribe el código"

Cada vez usamos más Copilot y Claude para generar código esto sin duda es un gran progreso.

Pero una IA solo es tan buena como el contexto que recibe. Aquí es donde cobran importancia los frameworks de agentes y librerías de skills.

AL Copilot Skills Collection

Tu framework Open-Source  con skills personalizadas centradas en desarrollo en AL. Esta extensión se encuentra en constante actualización por multiples compañeros de la comunidad.

Estas skills ayudan se activan dinámicamente cuando le pedimos a Copilot o Claude realizar un cambio que encaja con el propósito de una skill, esto ayuda al agente a generar mejor código paso a paso relacionado con diferentes funcionalidades

No solo generan código, sino que generan código alineado con patrones de funcionalidades ampliamente usadas de Business Central pero que Claude o Copilot no acaba de hacerlo bien sin el contexto de la skill.

Puedes Revisar las skills actuales y bajarte la extensión aquí:

AL Copilot Skills Collection - Visual Studio Marketplace

Home | AL Copilot Skills Collection

---

AL Development Collection

Mientras que la colección anterior está centrada en skills, esta es un framework de desarrollo en AL con un potencial impresionante.

ALDC Core no trae únicamente agentes personalizados con diferentes roles de BC, sino que a su vez incorpora también Instructions, prompts y Skills relacionados con el desarrollo en AL.

En lugar de empezar desde cero creando tu propia colección de agentes y buenas practicas para el desarrollo agentico en AL te aconsejo que pruebes ALDC, funciona  tanto para Github Copilot como para Claude Code y tiene además muy buena documentación que la convierte en una gran extensión que no puede faltar.

Te dejo aquí los enlaces:

AL Development Collection - Visual Studio Marketplace

AL Development Collection

---

3. La calidad no debería revisarse al final

Muchas veces ejecutamos las herramientas de revisión de código que garantizan la calidad de este justo antes del Pull Request, para entonces es demasiado tarde. 

Lo ideal es recibir feedback mientras escribimos el código, ya sea nosotros o con desarrollo agentico.

BC Quality

BC Quality ayuda precisamente en ese punto, ayuda a través de una estructura muy similar a la de skills a  revisar nuestros patrones de código y garantizar que seguimos estándares de calidad y que los agentes no alucinan demasiado hasta el punto que pierden buenos patrones de desarrollo en AL.

Permite detectar problemas durante el desarrollo y mantener un estándar homogéneo en el proyecto, y como ya sabes de sobra, cuanto antes aparece el problema, menos nos costará corregirlo.

Es la diferencia entre arreglar una línea y tener que rehacer una funcionalidad completa.

BC Quality también es otro framework Open-Source, directamente apoyado y mantenido tanto por Microsoft como por la comunidad.

microsoft/BCQuality: Quality skills and knowledge for Business Central development. The shared bar for humans and agents alike.

---

4. No todo debe acabar en Git

Este error es probablemente uno de los más repetidos.

Todos hemos visto repositorios con:

• archivos temporales
• símbolos
• paquetes
• configuraciones personales
• resultados de compilación

Nada de eso debería versionarse.

El papel del .gitignore

Un buen .gitignore evita que lleguen al repositorio archivos que:

• pueden regenerarse
• son específicos del equipo local
• no aportan valor al proyecto

Además mantiene los Pull Requests mucho más limpios.

Un ejemplo de lo que tendriamos dentro de nuestro archivo de .gitignore sería algo parecido a esto:

# =============================================================================

# AL Extension Build Artifacts

# =============================================================================

*.app

*.flf

*.bclicense

*.g.xlf

BuildOutput.txt

rad.json

# =============================================================================

# AL Compiler and Package Management Folders

# =============================================================================

.output/

.dependencies/

.buildartifacts/

.alpackages/

.packages/

.alcache/

# =============================================================================

# AL Development Tool Folders

# =============================================================================

.vscode/

.altemplates/

.altestrunner/

.snapshots/

# =============================================================================

# Configuration and Cache Files

# =============================================================================

.github/

.claude/

cache_*

# =============================================================================

# Test Results

# =============================================================================

TestResults*.xml

bcptTestResults*.json

# =============================================================================

# Operating System Files

# =============================================================================

.DS_Store

Thumbs.db

~$*

---

5. El objetivo no es escribir más código

Con el desarrollo asistido por IA ya no se trata únicamente de escribir código más rápido.

Se trata de construir un entorno donde el agente tenga toda la información necesaria para generar código correcto desde el principio.

Eso significa combinar:

• AL Cops para detectar problemas.
• AL Copilot Skills Collection para guiar en patrones de AL al agente.
• AL Development Collection para tener un marco de desarrollo agentico especializado en AL.
• BC Quality para mantener estándares de calidad.
• Un buen .gitignore para mantener limpio el repositorio.

Cada una resuelve un problema distinto, pero juntas forman una base mucho más sólida para un flujo de desarrollo moderno.

---

Conclusión

No existe la herramienta perfecta.

Pero sí existe un ecosistema de herramientas que reduce muchísimo los errores más habituales antes incluso de que lleguen a una revisión de código.

En un escenario donde cada vez delegamos más trabajo en asistentes y agentes, preparar correctamente el entorno de desarrollo deja de ser un "extra" para convertirse en parte del propio proceso de desarrollo.

Solemos decir que el mejor bug... sigue siendo el que nunca llega a escribirse pero ahora mismo tenemos gran cantidad de Frameworks construidos y mantenidos por la comunidad que nos pueden hacer la vida más sencilla de lo que nunca fue antes.

Nos vemos en la próxima parada del BC Scout Path 🧭

Remember: Talk is cheap, show me the Skills!