Skip to content
Brezel Docs
Blog

Brezel Style Guide

Naming Conventions

Defining Modules

  • File names: Use snake_case for file names. Example: incoming_invoices.bake.json
  • Identifiers: Use snake_case for identifiers. Example: incoming_invoices
  • Fields: Use snake_case for fields. Example: invoice_number
    • Choice values Use snake_case and lower case for values of field type choice. Example: [ "draft", "sent", "paid" ]

Branches

  • Branch names: Use kebab-case for branch names. Example: feature/add-new-feature
  • Branch prefixes: Use the following prefixes for branch names:
    • feature: For developing a new feature
    • bugfix: For fixing a bug
    • hotfix: For fixing a critical bug that needs to be deployed immediately
    • release: To prepare a new release, typically used to do last touches or revisions before a release

Commit messages

As most Brezel projects utilise the (semantic-release-bot)[https://semantic-release.gitbook.io/semantic-release], it is important to follow the commit message format for automated release. Even if a project does not utilise the bot, the format should still be followed at all times to ensure meaningful commits.

For standardization and automation purposes, we follow the Conventional Commits specification for commit messages which in itself is based on the (Angular convention)[https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format].

If you want to get further insights on what commit message type will trigger a release and their meanings for versioning, you can check the (semantic-release-bot docs)[https://semantic-release.gitbook.io/semantic-release#commit-message-format] on that.

Example

feat(invoices): add new feature

Commit Message Format

  • Prefixes: Use the following prefixes for commit messages:

    • feat: A new feature
    • fix: A bug fix
    • docs: Documentation only changes
    • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    • refactor: A code change that neither fixes a bug nor adds a feature
    • perf: A code change that improves performance
    • test: Adding missing tests or correcting existing tests
    • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

  • Scope: The scope could be anything specifying the place of the commit change. For example if it’s system-specific, it could be scoped to a module or functionality group like invoices, recipes etc. If you are contributing to the core, it could be recipes, permissions, etc.

Code Style

Most projects contain either a .editorconfig or .eslintrc file to enforce code style. Make sure your IDE respects those and warns you of violations.

If you are contributing to a project that does not have one, please follow the guidelines below.

Not respecting the guidelines may make the CI fail and block your code from reaching production.

Notable guidelines are:

  • Use camelCase for variables and functions
  • Single quotes for strings in PHP and JS/TS
  • No semicolons in JS/TS

PHP

Brezel roughly follows the PSR-12 coding standard.

In essence:

  • Use camelCase for variables and functions
  • Opening braces for classes and methods go on the next line
  • Single quotes for strings
  • 4 spaces for indentation

JavaScript / TypeScript / Vue.js components

Brezel follows the JavaScript Standard Style.

In essence:

  • Use camelCase for variables and functions
  • No semicolons
  • Single quotes for strings
  • 2 spaces for indentation

JSON

In essence:

  • 4 spaces for indentation
  • No trailing commas or other JSON5 features as it is not supported by all parsers