Skip to main content

Code Quality

We don't want bad or broken code to enter master. Therefore, we deployed some tools in each repository to check whether your committed code meets certain standard.

We use the following tools to enforce code quality checks:

  • TypeScript for web/backend projects
  • ESLint for web projects
  • SwiftLint for iOS projects
  • Android Linter (and optionally ktlint) for Android projects
  • flutter analyze for Flutter projects

TypeScript#

tip

If your project is having endless bugs due to type errors, you should consider migrating to TypeScript as long as possible.

note

All new DTI web projects should start with TypeScript

Run tsc to find all type errors. You must fix all type errors before you code can be accepted.

You can configure TypeScript in tsconfig.json. To enable strict type checking, you should add "strict": true to your compilerOptions in the json:

{
"compilerOptions": {
// ...
"strict": true
// ...
}
}

ESLint#

ESLint should already be setup in your web repository.

You should run npm run lint or yarn lint to find all the linter errors, and fix them before you commit or push.

You can configure the rules in .eslintrc/.eslintrc.json/.eslintrc.js at the root of your repository.

Your rules should start with this:

module.exports = {
extends: ['airbnb', 'plugin:@typescript-eslint/recommended', 'react-app'],
parser: '@typescript-eslint/parser',
plugins: ['@typescript-eslint', 'jest'],
env: { browser: true, node: true },
};

Examples rules:

SwiftLint#

Swiftlint should already be setup in your iOS repository.

You can run

./Pods/SwiftLint/swiftlint

to find all the linter errors.

You should run

./Pods/SwiftLint/swiftlint autocorrect

before you commit and push your changes.

You can configure the rules in .swiftlint.yml at the root of your repository.

This is a reference rule you should start with:

disabled_rules:
- colon
- identifier_name
- line_length
- function_body_length
- type_body_length
- force_cast
excluded:
- Pods
switch_case_alignment:
indented_cases: true

Disable rules that are too disruptive for your subteam.

Examples rules:

Android Linting#

Run

gradlew lint

to find all the linter errors. You should fix them before you commit or push.

If you are using Kotlin to develop Android apps, consider using ktlint and its gradle plugin.

flutter analyze#

You do not need to configure anything once you installed Flutter.

Simply run

flutter analyze

to find all the linter errors. You should fix them before you commit or push.