CopilotHub
SearchPromptsInstructionsAgentsToolsMCPs
  1. Home
  2. Instructions
  3. bicep code best practices.instructions
Back to Instructions

bicep code best practices.instructions

Coding standards for bicep code best practices.instructions

express
0 downloads
29 views
0

Tags

testing
security
documentation
api

Related Instructions

View all →

Python Docstring Standards

*.py

Write clear and consistent Python docstrings

python
python
documentation
+1
1
117

API Route Security

app/api/**/*.ts

Security best practices for Next.js API routes

typescript
nextjs
security
api
+2
0
113

WordPress Development — Copilot Instructions

Coding standards for wordpress.instructions

typescript
testing
security
+5
1
185

VueJS 3 Development Instructions

Coding standards for vuejs3.instructions

typescript
react
testing
security
+6
0
157

TypeScript MCP Server Development

Coding standards for typescript mcp server.instructions

typescript
express
testing
security
+5
0
126

TypeScript Development

These instructions assume projects are built with TypeScript 5.x (or newer) compiling to an ES2022 JavaScript baseline. Adjust guidance if your runtime requires older language targets or down-level transpilation.

typescript
express
testing
security
+6
0
143
Browse More Instructions

CopilotHub

A curated collection of prompts, instructions, agents, and tools for AI-powered development.

Quick Links

  • Prompts
  • Instructions
  • Agents
  • Tools
  • MCPs
  • Search

Browse by Category

  • Code Generation
  • Debugging
  • Documentation
  • Refactoring
  • Testing
  • Security

Legal

  • Guidelines
  • About
  • Privacy Policy
  • Terms of Service

Community

GitHub

© 2026 CopilotHub.

Naming Conventions

  • When writing Bicep code, use lowerCamelCase for all names (variables, parameters, resources)
  • Use resource type descriptive symbolic names (e.g., 'storageAccount' not 'storageAccountName')
  • Avoid using 'name' in a symbolic name as it represents the resource, not the resource's name
  • Avoid distinguishing variables and parameters by the use of suffixes

Structure and Declaration

  • Always declare parameters at the top of files with @description decorators
  • Use latest stable API versions for all resources
  • Use descriptive @description decorators for all parameters
  • Specify minimum and maximum character length for naming parameters

Parameters

  • Set default values that are safe for test environments (use low-cost pricing tiers)
  • Use @allowed decorator sparingly to avoid blocking valid deployments
  • Use parameters for settings that change between deployments

Variables

  • Variables automatically infer type from the resolved value
  • Use variables to contain complex expressions instead of embedding them directly in resource properties

Resource References

  • Use symbolic names for resource references instead of reference() or resourceId() functions
  • Create resource dependencies through symbolic names (resourceA.id) not explicit dependsOn
  • For accessing properties from other resources, use the 'existing' keyword instead of passing values through outputs

Resource Names

  • Use template expressions with uniqueString() to create meaningful and unique resource names
  • Add prefixes to uniqueString() results since some resources don't allow names starting with numbers

Child Resources

  • Avoid excessive nesting of child resources
  • Use parent property or nesting instead of constructing resource names for child resources

Security

  • Never include secrets or keys in outputs
  • Use resource properties directly in outputs (e.g., storageAccount.properties.primaryEndpoints)

Documentation

  • Include helpful // comments within your Bicep files to improve readability