Skip to content

Bicep Coding Standards

Canonical conventions for all Bicep in the Euvic Bicep module registry. These rules are applied passively by AI assistants (GitHub Copilot) when editing .bicep files, and are the reference for human authors.

Naming (prefix_snake_case)

Element Prefix Example
Parameter par_ par_location, par_registry_name
Variable var_ var_resource_group_name
Resource res_ res_storage_account
Module mod_ mod_log_analytics
Output out_ out_resource_id
Metadata mdt_ mdt_module_metadata
  • Always use par_location for the Azure region parameter (exception: services without region parity).
  • Use snake_case throughout; do not abbreviate beyond the prefixes above.

File structure

Every .bicep file starts with this header, filled in:

/*
SUMMARY: Short summary of what this file deploys.
DESCRIPTION: Longer description and any important upfront information.
AUTHOR/S: <author>
VERSION: 1.0.0
*/

Then, in order, with a section comment banner before each and a double line-break between sections: targetScope → Parameters → Variables → Resources → Modules → Outputs. Declare targetScope explicitly (tenant | managementGroup | subscription | resourceGroup).

Parameters & decorators

  • Every parameter and every output has an @description().
  • Add constraints with @allowed(), @minLength()/@maxLength(), @minValue()/@maxValue() where they protect input integrity.
  • Provide sensible default values wherever possible and note the default in the description.
  • @secure() for sensitive inputs only - never on outputs (outputs are stored/shown in plain text).
  • Prefer user-defined types for structured object/array parameters over loose object/array.

Code style

  • 2-space indentation.
  • Store conditional/loop expressions in variables for readability.
  • Use symbolic references (not reference()/resourceId() strings); avoid unnecessary dependsOn.
  • No hardcoded locations, environment URLs, or credentials - pass via parameters.
  • Comment non-obvious logic; include Microsoft Docs URLs where they aid understanding. An @description() that already covers intent does not need a duplicate comment.

Security

  • Never output secret/secure values; the outputs-should-not-contain-secrets linter rule is an error.
  • Use stable VM images; protect command-execution secrets.
  • Use current, pinned resource API versions.

Linting

All Bicep builds clean under the repo bicepconfig.json (linter rules set to error). Run az bicep build --file <file>.bicep before committing.

Reusable (registry) modules

Modules intended for reuse across projects live under the module registry repository and follow the module registry repository (metadata.json, version.txt, auto-generated README, publish flow). They are consumed via the br/Euvic-Modules alias - see that guide.