General guidelines

We’ve some common guidelines, and rules which are valid throughout all different programming languages.

Development configs

Reusable development configuration files must be stored in the Development configs project / repository.

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'

Data structures

Think about the format of your data structures, especially for extendible ones. For example:

# This works.
spam = ['i', 'hate', 'spam']

# But this is much better.
eggs = [
    'i',
    'like',
    'eggs',
]

Hint

If you’re expanding both lists and you make a diff, you’ll notice that the changes of spam are much harder to tell than the changes of eggs. Therefor prefer the multi- over the single-line format. Also make sure you always add a trailing comma to the last element as well.