Formatting & Lint

You may have noticed the project uses two static analysis tools: code formatters and linters:

• Formatters: Enforce consistent code syntax.

  • What: Specify tabs vs. spaces, line length, whitespace, etc.

  • Why: Aid collaboration and readability.

  • How: We use a common formatter called Prettier.

• Linters: Enforce good semantics of code (as well as syntax).

  • What: Disallow unused variables & misused promises, obligate specifying function type, etc.

  • Why: Prevent defects, or changes that commonly evolve into defects.

  • How: We use a linter called descriptive which extends rules from ESLint and Typescript-ESLint but are specifically tailored to the needs of 310.

Both formatters and linters are used by most industrial teams to make it easier for developers to collaborate by making code easier to read, understand, and maintain. 

We have chosen the following default lint rules for the project:

Customizing Your Usage

Static analysis tools are only as useful as their users find them to be. Therefore, you are allowed to modify your usage of static analysis in the following ways:

Linting:

You and your partner may modify the .eslintrc.js file to whatever fits your needs, adding, removing, or modifying any rules (you may use any rules from the descriptive, eslint, or typescript-eslint plugins). Whatever rules are specified in your file will also be the ones run by AutoTest in its linting phase.

If you remove or rename .eslintrc.js, lint will be skipped by AutoTest; if you later re-commit .eslintrc.js lint will once again be checked by AutoTest. Be sure to discuss with your partner before making any changes, since it will apply to the entire project repository once committed. 

Formatting:

You may NOT modify formatting from the default settings. Prettier is opinionated about how code is formatted (and not allowing much customization) so there is no need to deviate from this (and your IDE should handle formatting automatically if configured properly!). This also solves a common source of challenges (and merge conflicts) for 310 teams, so code must always conform to formatting style guide.