format-bicep

name	format-bicep
description	Format Bicep code for readability and consistency.

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'
  }
}