0540c7bf6e
The 35 articles still in their seed form previously carried a banner reading "Seed article. ... Domain stewards should expand, restructure, and refine as needed." For a community preview, that phrasing reads as "TODO left in production" to first-time visitors. Replace all three banner variants (performance-seeded, security-seeded, community-ported) with a single positive invitation: > Contributions welcome — open a PR to refine or extend this article. Content and structure of the articles are unchanged; only the leading quote block differs. Articles that had their banner fully stripped in the earlier triage pass (the showcase-grade ten) are unaffected.
1.1 KiB
| bc-version | domain | keywords | technologies | countries | application-area | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
performance |
|
|
|
|
Prefer direct record access over RecordRef where possible
Contributions welcome — open a PR to refine or extend this article.
Description
RecordRef and FieldRef are the platform's reflection API: they work across tables the compiler does not know at authoring time. That flexibility costs per-operation overhead — every field access goes through a lookup — and loses compile-time type checking. For operations where the table is known, a strongly-typed Record variable is simpler and faster.
Best Practice
Use Record variables for code paths that target a known table. Reach for RecordRef and FieldRef only when the table is genuinely dynamic (generic export/import, field-agnostic utilities, cross-table integrations).
See sample: prefer-direct-record-over-recordref.good.al.
Anti Pattern
Using RecordRef as a habit, even when the target table is hardcoded two lines earlier, costs performance and hides intent from reviewers.
See sample: prefer-direct-record-over-recordref.bad.al.