Format Bicep

Format Bicep

This skill reformats Bicep code to enhance readability and maintainability by applying consistent styling, indentation, and organization.

Guidelines

To format a Bicep file, follow these guidelines:

Bicep structure

To avoid chaos keep a strict structure for Bicep files. The recommended structure is as follows:

// Imports

// Metadata (optional)

// TargetScope (optional)

// Parameters

// Variables

// Existing resource references

// Resources / Modules

// Outputs

// User-Defined Types Types

// Functions

Do not add blank lines between section comment headers and the first definition in that section.

Correct:

// Parameters
@description('The supported Azure location')
param location string

Wrong:

// Parameters

@description('The supported Azure location')
param location string

Property order on resource and modules

Resource definitions should follow a consistent property order:

resource <name> '<type>@<apiVersion>' = {
  name: '<name>'
  location: '<location>'
  tags: '<tags>'
  <property>: '<otherProperties>' // other resource-specific properties in alphabetical order
  dependsOn: [
    // dependencies
  ] // optional, prefer implicit dependencies
  properties: {
    // resource-specific properties
  }
}

Module defitinitions should follow a consistent property order. If the module has the name property, it should be removed since the Azure Resource Manager handles the deployment name.

module <name> '<path>' = {
  scope: '<scope>' // optional
  identity: {
    // identity properties
  } // optional
  dependsOn: [
    // dependencies
  ] // optional, prefer implicit dependencies
  params: {
    // module parameters
  }
}

Reference naming

Resources which have an existing reference should have the name ending with Ref. For example:

resource subnetRef '<type>@<apiVersion>' existing = {
    ...
}

Execution steps

When formatting a Bicep file, perform these steps in order:

1. Analyze the current structure

   • Identify existing sections (parameters, variables, resources, etc.)
   • Note any missing required sections

2. Reorganize sections according to the standard structure

   • Move items to their correct section
   • Add section comment headers if missing
   • Ensure to return feedback about any significant structural changes made. DO NOT REMOVE any code, only reorganize it.

3. Apply property ordering

   • Reorder resource/module properties as specified
   • Ensure decorators are in the correct order

4. Run bicep format

   • Run command: bicep format <.bicep file>

5. Remove commented code

   • Delete any commented-out code blocks
   • Retain comments that provide context or explanations

6. Validate the result

   • Ensure no syntax errors were introduced
   • Verify the file compiles successfully

Use the following command to compile and validate the Bicep file:

  bicep build <.bicep file> --stdout --no-restore

Examples

Before Formatting

param location string='eastus'
var storageAccountName='mystorageaccount'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01'={
    name:storageAccountName
    location:location
    properties:{
        accessTier:'Hot'
    }
    sku: {
        name: 'Standard_LRS'
    }
}

After Formatting

// Parameters
@sys.description('The Azure region for resource deployment')
param location string = 'eastus'

// Variables
var storageAccountName = 'mystorageaccount'

// Resources
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    accessTier: 'Hot'
  }
}