Still lot of projects are lead on “old” ways, not changing to new approaches.
Every developer makes mistakes when it comes to coding. Some come from rushing deadlines, others from old practices that don’t hold up anymore.
Table of contents
Testing Isn’t Optional
Every pull request should come with tests. Period. Tests verify that code works as expected, now and in the future. Automated tests in CI/CD pipelines also catch regressions before they reach production. Building a strong culture of testing benefits everyone—from the developers writing the code to the users relying on it.

Rethink Tooltips
Bad tooltips are a missed opportunity. Copying a field’s caption into the tooltip field doesn’t add value. Developers also use automatically generated ones, but they need to step in and add real context when needed.
Don’t forget now that it’s new practice to move all Tooltips on table level. For that you can use AL Language predefined actions by position on Tooltip and than pressing Crtl + .:

Avoid Approaches Like “Application Area = All”
Defaulting to “All” when setting application areas is lazy and defeats the purpose of application areas. Specificity matters. Assigning particular fields or features to proper application areas ensures a better user experience. Microsoft even offers tools to make setting application areas easier—there’s no excuse for doing it wrong.
Here is also documentation how you can extend Application Areas:
Extending Application Areas – Business Central | Microsoft Learn
Don’t Mindlessly Comment Out Code
Commenting out chunks of code and leaving it in your repository forever? It’s a recipe for confusion. Comments should explain why something is there, not hold unused code “just in case.” If you want to keep something, use tools like Git for version tracking or conditional directives for clarity. Otherwise, delete it.
Not:

Git:

Share Settings, Avoid Chaos
Another overlooked practice: committing shared settings to repositories. Consistent settings help teams align on formatters, code analyzers, and extensions. This prevents conflicts between personal and collaborative environments. Save user-specific customizations for personal files—repository settings should enforce team standards.
For example:

Snippets and Shortcuts: Time-Saving Essentials
If you’re not using snippets, you’re leaving time on the table. Snippets allow you to generate repeatable code structures instantly. They’re a lifesaver for frequently-used logic. Similarly, mastering keyboard shortcuts in tools like Visual Studio Code drastically boosts efficiency. The less time spent clicking through menus, the faster you’ll get to the real work.
Syntax and snippets – Business Central | Microsoft Learn
Keyboard shortcuts for AL in Visual Studio Code – Business Central | Microsoft Learn
Deployment Without Automation is a Nightmare
It’s time-consuming, error-prone, and totally unnecessary. Automating deployments ensures consistency across environments and allows developers to manage large systems with dozens—or even hundreds—of apps.
Take advantage of pipelines to streamline deployments. Whether on-prem or SaaS, automated processes handle complex dependency trees quickly, freeing developers to focus on the bigger picture.
You can check AL:Go, ALOps or Alpaca
Code Reviews and Automated Tools Are Necessary
Think your code doesn’t need reviews? Think again. Code reviews not only help catch errors early but also improve overall consistency. They’re critical for maintaining standards, especially in collaborative projects. A fresh pair of eyes can make all the difference.
In addition, tools like linters and code cops enhance quality by flagging minor issues before they become major headaches. Automation eliminates the human error of overlooking best practices, leaving the team to focus on meaningful development work.
Obsessing Over Object IDs
One bad habit that stood out was developers assigning unnecessary meaning to object IDs. For example, many still associate specific IDs—like table 18 for customers or table 27 for items—with a predefined purpose. Object IDs once added structure, but in today’s environment, they’re often irrelevant.
Some even use IDs in file names or to organize fields. This practice doesn’t make sense anymore. Modern tools like Git simplify searching and organizing files. Clinging to numeric ranges just adds clutter without improving efficiency.

Is AL Always the Right Tool?
Sometimes, the best solution isn’t AL. Heavy computations or front-end-specific processes often perform better in Azure Functions or web technologies. If a task doesn’t interact with Business Central data, ask yourself: Could this live outside AL?
Clean Deprecation Practices
When deprecating code, plan it carefully. Functions should remain accessible with clear obsolescence notices until they can be safely removed. Don’t delete fields or tables without thinking through upgrade paths. Avoiding disruptions keeps everyone happy—especially your users.
Extensibility Is a Big Problem
Extensibility is no longer optional—it’s essential. Modern development environments like Business Central require developers to think about how their code will be extended by others. This includes putting event publishers in place and managing extensible ENum’s responsibly.
Skipping this step might seem faster in the short term, but it creates long-term issues when you need to modify or integrate the code later. Plan for extensibility from day one.
Software development evolves. Old habits fade as new tools and practices take their place. By challenging bad habits and adopting smarter workflows, developers make their code easier to maintain and more adaptable for the future. When in doubt, question your process, and don’t be afraid to change. Your future self—and your users—will thank you. Keep following, there will be definitely more on this topic!
Subscribe to our email newsletter to get the latest posts delivered right to your email.
Comments