6fb794bc79
* Delete outdated development instructions for Next.js + Tailwind and Python; add comprehensive guidelines for PostgreSQL DBA, Angular, ASP.NET REST APIs, Azure Functions with TypeScript, Bicep, Blazor, CMake with vcpkg, C#, .NET MAUI, GenAIScript, Terraform for Azure, localization, and markdown standards. * Update documentation and prompts for consistency and clarity - Standardized description formatting in various markdown files to use single quotes. - Added error handling utility in update-readme.js for safer file operations. - Improved title extraction logic in update-readme.js to handle frontmatter more robustly. - Updated chat modes section in README to reflect new emoji and sorted chat mode links. - Cleaned up various instruction files for better readability and consistency. - Ensured all markdown files end with a newline for better compatibility with version control. * Remove standardize-frontmatter.js script * Add usage instructions for creating and switching chat modes in README.md * Update README.md generation script to enhance instructions and usage details for custom chat modes * Update README.md and update-readme.js for improved instruction clarity and consistency * Refactor README.md links and update readme script for improved clarity and consistency in instructions * Update README.md and update-readme.js for improved instruction clarity and consistency * Changing from a patch to regen approach for the readme * Bit more cleanup for how to show things in the readme * Adding missing description * Another missing description --------- Co-authored-by: Aaron Powell <me@aaron-powell.com>
55 lines
2.1 KiB
Markdown
55 lines
2.1 KiB
Markdown
---
|
|
description: 'Infrastructure as Code with Bicep'
|
|
applyTo: '**/*.bicep'
|
|
---
|
|
|
|
## 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
|