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.

Indentation

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

Hint

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

Important

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

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


# INCORRECT: Consistent spaces (4), invalid syntax

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


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

  object:
      - 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'