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 preventspyc
,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