-
Notifications
You must be signed in to change notification settings - Fork 1
contribution guide
Levin Eric Zimmermann edited this page Apr 15, 2022
·
12 revisions
- use
import module
instead offrom module import something
, follow pep8-guidelines regarding imports (1. Standard library imports, 2. Related third party imports, 3. Local application/library specific imports.) - consider writing a static method if a utility function is only used in one class
- always use typing and test via mypy
- use DOC-strings with sphinx docstring format
- use format style Black (max-line-length 88 characters)
- use relative imports within modules
- write one module (several classes or functions) per file and add all public functions and classes to a global
__all__
variable at the beginning of the file
- use plural form for module names
- avoid plurals as variable names: better write VARIABLE_TYPE, for instance
pitch_list
orpitch_tuple
instead ofpitches
- use consistent and meaningful variable names in methods (e.g. the classname written in lowercase)
- avoid abbreviations (because abbreviations make it more difficult for anyone who is new to the library)
- converter names should have the form
InputToOutput
e.g.MilkToCheese
orGrapeToWine
- mutwo modules should have the form
EXTENSION_MODULE
whereEXTENSION
is the name of the mutwo extension andMODULE
is one of the standard mutwo module names (events
orparameters
orgenerators
orutilities
orconverters
orconstants
: see next sectionmodules
), e.g.karawaitan_parameters
for extensionmutwo.ext-karawitan
- mutwo modules have standarised names for certain functionalities
-
converters
: convert external data to mutwo, convert mutwo data to external data, convert mutwo data to mutwo data -
events
: all classes which inherit from basic mutwo building blockmutwo.core_events.abc.Event
-
generators
: classes, methods, functions, constants to create data helpful for art works -
parameters
: attributes for events and related classes -
utilities
: utility functions, decorators, exception classes, etc.
-
- commits should be atomic (types of changes should be grouped together)
- please try to follow this guide regarding commit messages