Guidelines and code style

Table of contents

• Guidelines
  • Pull Requests Guideline
  • Commits Guideline
    • Structure of a commit
    • The different tags
    • Examples
• Code style
  • Install rustfmt
  • Running rustfmt

Guidelines

This section will help you to follow Epic's guidelines

Pull Requests Guideline

A good PR should follow these rules:

• Keep it small

Giant snippets of code can make the reviewer lose track of the features that are being merged. A reviewer can only process 400 lines of code before his ability to find defects in the code start to diminish (Cisco Systems study).

• Keep it clean

Remove all comments and keep your commit history clean. Rebase with the develop branch before opening a PR.

• Keep paying attention

Review your own code before asking for an external review

• Keep a good attitude

Before submitting a PR ensure that:

• The PR template was filed correctly
• It has a good explanation of what was changed
• Explain if it will break any existing functionality
• Describe how you have tested it
• Updates any documentation that's affected by the PR

The Epic Team will make its best to help you with anything that you may need to reach the best code.

Commits Guideline

For the Epic Cash projects, we are currently using conventional commits to ensure a good commit history. More information about conventional commits can be found on its web page.

Here are the basics of conventional commits:

Structure of a commit

Usually, the conventional commits will have the following structure:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The different tags

As the type on the commit message, it can be one of the following:

• feat: Commits that adds a new feature.
• fix: Commits that fixes a bug.
• refactor: Commits that rewrite/restructure your code, but does not change any behavior.
• perf: Commits are special refactor commits, that improve performance.
• style: Commits that do not affect the meaning (white space, formatting, missing semi-colons, etc).
• test: Commits that add missing tests or correct existing tests.
• docs: Commits that affect documentation only.
• build: Commits that affect build components like build tool, ci pipeline, dependencies, and project version.
• ops: Commits that affect operational components like infrastructure, deployment, backup, and recovery.
• chore: Miscellaneous commits e.g. modifying .gitignore.

Examples

• Commit message with description and breaking change footer

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

• Commit message with ! to draw attention to breaking change

feat!: send an email to the customer when a product is shipped

• Commit message with no body

docs: correct spelling of CHANGELOG

• Commit message with scope

feat(lang): add polish language

Code style

This project uses rustfmt to maintain consistent formatting. We've made sure that rustfmt runs automatically, but you must install rustfmt manually first.

Install rustfmt

Run the following to install rustfmt

rustup component add rustfmt
rustfmt --version

Then run cargo build to activate a git pre-commit hook that automates the rustfmt usage.

Running rustfmt

The rustfmt is set to run automatically on each new git commit. You can change the current behavior by configuring the ./.hooks/pre-commit

You can also run rustfmt manually by using:

rustfmt <file>