How I turned 200+ BCQuality knowledge files into 26 AL rules (and rejected most of the rest)

Yahya Touil — Mon, 24 Aug 2026 10:41:50 +0000

I just shipped AL Griller, a static analyzer for Dynamics 365 Business Central AL code that roasts you when it finds a real problem. Before I talk about the jokes, I want to talk about the boring part, because the boring part is the reason the jokes are trustworthy: how the 26 rules actually got chosen.

Disclosure up front: AL Griller's rule research was built by working through Microsoft's BCQuality repository - a curated knowledge base and skills library for Business Central quality. Full credit to the BCQuality team and community for that research. AL Griller is an independent, community-run open-source project. It is not a Microsoft product and there's no official partnership.

The starting point

BCQuality is big - north of 200 knowledge files across 14 domains (performance, query, data modeling, error handling, events, security, and more). Not every one of those files can become a static analysis rule. A lot of them describe judgment calls: "reorder this switch by frequency, but only if profiling shows it's hot," or "pick the right key based on read/write ratio." Real advice, completely useless as a line-matching rule, because it needs information a single-file text scanner will never have.

So the research pass wasn't "convert every file to a rule." It was a filter, applied file by file:

Is this a meaningful practice?
Is it deterministic?
Is it detectable from AL source without AI?
Are false positives controllable?
Is it explainable?
Is it testable?
Is it already covered by a Microsoft analyzer (CodeCop / AppSourceCop / PerTenantExtensionCop / UICop)?

Full reads went into Performance (54 files), Query, Data Modeling, Error Handling, the community layer, and the Events files specific to loop/database behavior. Security got a representative sample (8 of ~20 files, chosen for deterministic detectability). Domains like Privacy, Telemetry, Testing, and Interfaces got only a file-listing pass - flagged as future research, not "nothing there."

What survived

Everything that passed the filter got classified STRONG / GOOD / EXPERIMENTAL, and every rule that actually shipped got a priority: P0 or P1.

P0 (12 rules) - purely syntactic or local to a single procedure/trigger, with short, reliable false-positive carve-outs.
P1 (14 rules) - still deterministic, but needs cross-statement ordering within a procedure, a light heuristic, or one extra piece of context.

That's the entire shipped set: 26 rules, ALGRILL001–ALGRILL026. No P2 or P3 rules made it into rules.json. That was a deliberate call - the project's own research doc calls it "trust over rule count." A rule that's right 80% of the time and annoying the other 20% erodes trust in every other rule it ships next to.

What got rejected outright

A handful of well-documented BCQuality patterns were investigated and explicitly rejected - not deferred, rejected - because they fail on a fundamental axis rather than just confidence:

Error message tone (internal vs. client-facing) - requires judging the tone of English prose. Not a syntactic pattern.
Hand-rolled validation error accumulation - the anti-pattern has too many unrelated shapes (a List, a TextBuilder, a temp table, plain concatenation) to match reliably.
Case-branch reordering by frequency - the source article itself says this is only justified when profiling shows a hot path. Not statically detectable, and explicitly called out as "not a default review finding."
SetCurrentKey alignment with filters - picking the "right" key requires understanding business-relevant filter/sort intent that isn't recoverable from source. The original task brief flagged this one specifically as a trap: don't manufacture "SetCurrentKey after FindSet = bad" out of it.

What's deferred, not rejected

A separate bucket - real, well-evidenced findings that didn't clear the bar this pass, usually because reliable detection needs cross-object context a single-file scanner can't resolve:

N+1 Get()/FindFirst() in a loop, refined by "and a query/dictionary would have collapsed it" - needs join-feasibility awareness across tables.
Missing SetLoadFields() - the source article lists four separate suppression conditions (field count, field-read percentage, loop iteration bound, temp/singleton exemption). Shipping without all four would produce exactly the false-positive fatigue the project was trying to avoid.
Setup-table singleton detection - currently only a naming heuristic (*Setup, blank Code[10] key), with real false-positive risk on legitimately multi-row tables that happen to end in "Setup."

These are recorded in the research doc specifically so a future contributor doesn't have to re-derive them from scratch.

Why this matters for the roasts

Every AL Griller finding carries a joke, but the joke only exists because the pattern underneath it survived that filter. ALGRILL003 doesn't say "consider CalcSums." It says CalcFields() "got summoned once per row like a tiny genie who can only grant one wish before vanishing back into the lamp, forever, on repeat" - and then, one click away under "Technical details," the actual mechanism: one SQL round trip per row vs. one aggregate query. The joke is decoration. The finding underneath has to survive the same bar CodeCop's own rules would.

Where this goes next

BCQuality is an active, growing project, and AL Griller's rule set is meant to track it over time rather than freeze at v1.0.0. If you work in AL and know a pattern that should be a rule - or have a better roast for an existing one - PRs are genuinely welcome. New rules need the same false-positive discipline described above; new roasts just need to be specific to the pattern, not generic.

Repo: https://github.com/yahyatouil-dev/al-griller
BCQuality (the research this is built on): https://github.com/microsoft/BCQuality
Read More: https://yahyatouil.com/posts/bcquality-for-business-central-how-to-use-it-with-ai-and-vs-code/

I built 7 VS Code tools for Business Central developers because the workflow pain was real

Yahya Touil — Thu, 05 Mar 2026 20:26:32 +0000

Field 19 of 43. Typed by hand. From a JSON response.

That was the moment I stopped accepting the workflow and started building something better.

Business Central development carries a lot of invisible overhead, and none of it is the hard part. It's the boilerplate, the folder setup, the JSON-to-AL mapping, the constant Postman context switching. Mechanical work that consumes focus without earning it.

I spent six months building BC HERO: a free VS Code extension with seven tools that eliminate the most painful parts of the AL development workflow.

What's inside:

🗂️ Quick Project Setup - select your AL component folders, preview the structure, generate in one click. No more five-minute directory rituals.

🧱 AL Object Creator - is a focused, single-screen workflow for creating a table and related objects. Configure the table, fields, and objects, then generate and review everything in one place.

⚡ JSON → AL Generator - drop a JSON file (plain objects, arrays, OData { "value": [...] } all work). BC HERO infers AL types, lets you customize, outputs syntax-highlighted AL. 30 fields in about 3 minutes instead of 25.

🔌 API Explorer - full HTTP client inside VS Code. Scans your workspace for API pages and queries. Basic Auth and OAuth 2.0. I haven't opened Postman for a BC project since I built this.

🌍 Translation Assistant - visual XLIFF editor with progress bars, inline editing, validation, and batch updates. A 200-unit review cycle went from over an hour to under 20 minutes.

📊 Schema Viewer - interactive force-directed graph of your table relationships with field metadata sidebar. First thing I open in an unfamiliar codebase.

🔗 Dependency Graph - visualization of every object in your workspace, color-coded by type, with directed dependency edges.
It's free and always will be.

Full story and design rationale on my blog 👉 blog link

VS Code Marketplace 👉 https://marketplace.visualstudio.com/items?itemName=yahyatouil.bc-hero

GitHub (issues, roadmap) 👉 https://github.com/yahyatouil-dev/bc-hero-info

DEV Community: Yahya Touil