Linters introduction#

The Karen mode#

Most linters bring along recommended configurations or rules. Usually this includes only a subset of all available rules, and a lot will be deactivated by default. You can also call this whitelisting, since only a selected set of rules is activated.

However, we don’t want that behaviour. We want the linter to complain about every possible violation, i.e. set it in Karen Mode. Instead of whitelisting rules, we want blacklist or customise rules we don’t like. This means we’re activating all rules by default and start overwriting the ones we don’t like.

Common rules#

There are some common rules which are valid throughout all different programming languages and linters.

Line length#

The maximum line length is always set to 100 characters.


We usually use 4 spaces and we never use tabs to indent code, regardless of the file size.


Of course there are exceptions for files which are picky about the number of spaces or tabs, such as a Makefile.


For YAML we make an exception of 2 spaces, due to the indentation for objects / dicts in lists. YAML is always consistent & valid w/ 2 spaces. With 4 spaces, it has either inconsistent whitespaces or invalid syntax, as they’re mutually exclusive:

# CORRECT: Consistent spaces (2), valid syntax

    - foo: 'Foo'
      bar: 'Bar' # <-- correct indentation, correct amount of spaces
# ^^
# 12^^
#   12

# INCORRECT: Consistent spaces (4), invalid syntax

      - foo: 'Foo'
          bar: 'Bar' # <-- wrong indentation, correct amount of spaces
# ^^^^
# 1234^^^^
#     1234

# INCORRECT: Inconsistent spaces (2 & 4), valid syntax

      - foo: 'Foo'
        bar: 'Bar' # <-- correct indentation, incorrect amount of spaces
# ^^^^
# 1234^^
#     12

Variable assignment alignment#

Readability counts and thus variable assignments can / should be aligned like this:

short_var       = 'example'
longer_var      = 'example'
a_very_long_var = 'example'