Coding standards
Naming, logging, error handling and review habits that keep a platform maintainable across teams.
Naming, logging, error handling and review habits that keep a platform maintainable across teams.
- Name things by intent so the next admin understands them
- Gate debug logging behind a property
- Review for failure paths and scale, not only correctness
- The common anti patterns are well known, ban them explicitly
Naming and structure
Prefix custom tables and fields with u_ in global scope, or rely on the scope namespace in scoped apps. Name business rules with the intent, not the mechanism, for example Close parent when all children closed rather than BR incident 3.
Logging
Use gs.info, gs.warn and gs.error with a consistent prefix so logs are searchable. Never log personal data or credentials. Wrap verbose logging behind a property so debug output can be switched on in production for one hour rather than living there forever.
var LOG = 'ACME Orders: ';
if (gs.getProperty('x_acme.orders.debug','false') === 'true') {
gs.info(LOG + 'payload ' + JSON.stringify(safePayload));
}Review habits
A short checklist catches most defects.
- Does it run only when it must, with a tight condition
- Does it handle the failure path, not just the happy path
- Is anything hard coded that belongs in a property or a system table
- Will it still work when the record count is a hundred times larger
What to avoid
No synchronous GlideAjax, no GlideRecord in client scripts, no current.update() in before rules, no gs.sleep, and no unfiltered queries in loops. These five account for most performance escalations.