My coding style guidelines for different programming languages.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Jannik Beyerstedt 6bf576f1cc add CSS style 6 months ago
LICENSE Update 'LICENSE' 6 months ago add CSS style 6 months ago migrate from github gist and cleanup/ update content 6 months ago add CSS style 6 months ago migrate from github gist and cleanup/ update content 6 months ago migrate from github gist and cleanup/ update content 6 months ago

Coding Style Guidelines

This is my (currently quite messy) collection of coding styles and other coding related rules. Most things should be quite generally applicable and common sense, some others might just be my personal taste. But feel free to use this as a base for your own style or even comment/ contribute to this.


This file contains some general rules, which apply to most programming languages. Individual style guides are available in other files for:

Also see my project dotfiles and templates in:

General Workflow

  • Use a version control system, e.g. Git
  • Couple your documentation versioning to the source code
    • Write documentation as plain text files, e.g. in Markdown syntax
    • If reasonably possible, also provides model and diagram sources. But do not put large binary blobs in the repository.



  • File and folder names (of your source code) should:
    • Just contain lower case characters
    • Not contain spaces
    • Separate prefixes with a dash and words with an underscore, like topic-foo_bar.txt
    • Contain none of these special characters |/\~!?=^%&$
  • Structure your code in a reasonable way into folders


General rules:

  • Use it!
  • Do not commit binary blobs (or have a good reason for it)
  • Never commit
  • List things, that should not be committed, in the .gitignore file. (Use readily available templates for your programing language)
  • Only commit a state, which at least compiles without errors and even better is a runnable version


  • Commits should contain one single/ standalone change or (step towards a) feature
  • The code state in a commit should
    • at least compile without errors
    • better: compile without warnings
    • best: be tested to run as expected
  • Commit messages should:
    • The description should use imperative language in present tense, e.g. fix bug/ add new form field
    • If only a certain module was changed, prefix the description with the module name, e.g. moduleX: add some more logging
    • Use a tag to annotate special changes, like:
      • [DOC]: if only documentation was changed
      • [FIX]: for bug fixes
      • [TIDY]: for refactoring actions and other cleanup steps. No functionality should be changed here!

Branching Model (adapted from git-flow):

  • First of all, take use of the branches!
  • Use a master branch for the current stable version AND a develop branch for the current state of development
  • Use branches named feature/$your_feature_name to develop features without interfering with the develop branch.
  • Therefore: Use a branch and merge (Pull request/ Merge Request) workflow. Even if your on your own!