Linters

Linter mode

We love linters complaining about every possible violation, thus we set it in Karen mode by:

• Skip on “recommended” configurations

• Enabling all the rules instead

• Explicitly deactivating, or customising the ones we don’t like

Note

Most linters bring along recommended configurations, but these often have rules inactive by design. We’re in favour of a «blacklisting approach», rather than that «whitelisting approach», thus we skip on those recommended configurations.

Linter configurations

As mentioned in the 🎯 Zen, «consistency counts». This also applies to the linter configuration, which should be consistent across different projects. Thus the linter configuration files are stored in the central Development configs project, resp. Git repository in the linters directory.

Important

We’re leveraging Git commits to document changes on the configuration files. However, the configuration file itself also contain documentation, esp. reasons why we’ve deactivated, or customised certain rules.

Python linters

isort

We’re using isort to sort our Python imports.

See also

Have a look at our centralised isort configuration for the exact configuration.

Hint

Leverage the central linter configs, by using the following Make target:

isort:
    curl -sSfLo .isort.cfg $(LINTER_CONFIGS)/isort.cfg
    isort $(SOURCE_FILES)

test-isort:
    curl -sSfLo .isort.cfg $(LINTER_CONFIGS)/isort.cfg
    isort -c --diff $(SOURCE_FILES)

pycodestyle

We’re using pycodestyle to do some basic checks in Python, which will not be done by Pylint.

See also

Have a look at our centralised pycodestyle configuration for the exact configuration.

Hint

Leverage the central linter configs, by using the following Make target:

test-pycodestyle:
    curl -sSfLo tox.ini $(LINTER_CONFIGS)/tox.ini
    pycodestyle $(SOURCE_FILES)

Pylint

We’re using Pylint to do extensive linting in Python.

See also

Have a look at our centralised Pylint configuration for the exact configuration.

Hint

Leverage the central linter configs, by using the following Make target:

test-pylint:
    curl -sSfLo .pylintrc $(LINTER_CONFIGS)/pylintrc
    pylint $(SOURCE_FILES)

Coverage.py

We use Coverage.py to measure code coverage of our unit tests.

See also

Have a look at our centralised Coverage.py configuration for the exact configuration.

Hint

Leverage the central linter configs, by using the following Make target:

test-{SCOPE}:
    curl -sSfLo .coveragerc $(LINTER_CONFIGS)/coveragerc
    coverage run {TEST COMMAND}

test-coverage:
    coverage report -m

Web linters

ESLint

We’re using ESLint to do the linting of JavaScript files.

See also

Have a look at our centralised ESLint configuration for the exact configuration.

Hint

Leverage the central linter configs, by using the following Make target:

test-eslint:
    curl -sSfLo .eslintrc.yml $(LINTER_CONFIGS)/eslintrc.yml
    npx eslint $(SOURCE_FILES)/**/*.js

stylelint

We’re using stylelint to do the linting of CSS files.

See also

Have a look at our centralised stylelint configuration for the exact configuration.

Hint

Leverage the central linter configs, by using the following Make target:

test-stylelint:
    curl -sSfLo .stylelintrc.yml $(LINTER_CONFIGS)/stylelintrc.yml
    npx stylelint $(SOURCE_FILES)/**/*.js