Guidelines for contributors - acdh-oeaw/wugsy GitHub Wiki

In this document we outline coding and contribution style.

General

  • Semantic versioning to be followed always: https://semver.org/
  • Never hardcode any local path anything ever ever
  • Never commit your virtualenv or .idea
  • Put this local stuff in your .gitignore, which we should share. Its existence currently prevents pyc, DS_Store, etc, thank god. Local configs should also not be committed, but you can commit changes to the default one if there is a new setting.

Python

@interrogator is head of Python, and can be awfully strict. It's for our own good. Here are some rules to follow for regular contributors. We can be more gentle if we get PRs from the public

Coding conventions

  • All exceptions named, handled and logged
  • Max 3 levels of indentation when possible
  • make things into classes when you can
  • Use argument unpacking, zip, use **kwargs but not for every func/method
  • use `dictionary.get('item', 'nothing') instead of the try/KeyError misery
  • Decorators are awesome
  • List comprehensions are also dope, and more performant than for loops

Editor

Recommended editor is Sublime Text 3, but Atom, PyCharm and of course vim/emacs still OK.

Linting

Linting checks code style, and can help you spot errors. It really helps keep the code nice.

Use pylint set up for Python 3. Set it up for your editor however you need, and make sure it uses the pylintrc file we have in base of repo. Let me know if you want to customise the settings file, for example, add a variable name that should be allowed (I have disabled data, lst and some other names that suck)

Whitespace

We want no trailing whitespace on lines, including blank lines. Set your editor up to do this, or set up a git hook that does it on commit.

General PEP compliance

Stick as closely to possible to PEP guidelines, though use Google docstrings instead of RST. Any user-facing classes and methods need complete documentation of args, kwargs and return type, but stuff deep in the backend it's ok to just have a one line description. But yes, there should always be a docstring with text on own line please:

def return_five():
    """
    Gives you 5
    """
    return 5

Any other languages

Sorry, I don't know. Someone else add