contribution guide

programming style guide

1. if possible: use import module instead of from module import something
2. for mutwo modules: always use from mutwo import ...
3. follow pep8-guidelines regarding import order (1. Standard library imports, 2. Related third party imports, 3. Local application/library specific imports.)
4. consider writing a static method if a utility function is only used in one class
5. always use typing and test via mypy
6. use DOC-strings with sphinx docstring format
7. use format style Black (max-line-length 88 characters)
8. use relative imports within modules
9. 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

naming conventions

1. use...
   1. snake_case for
      • methods
      • functions
      • modules
      • arguments
      • local variables
   2. CamelCase for classes
   3. upper SNAKE_CASE for global constants
2. use plural form for module names
3. avoid plural form for variable names: better write VARIABLE_TYPE, for instance pitch_list or pitch_tuple instead of pitches
4. use VARIABLE_count for length of sequence (e.g. pitch_count = len(pitch_list))
5. use VARIABLE_index for index variable (e.g. for pitch_index, pitch in enumerate(pitch_list):)
6. use consistent and meaningful variable names in methods (e.g. the classname written in lowercase)
7. avoid abbreviations (because abbreviations make it more difficult for anyone who is new to the library)
8. converter names should have the form InputToOutput e.g. MilkToCheese or GrapeToWine
9. mutwo modules should have the form EXTENSION_MODULE where EXTENSION is the name of the mutwo extension and MODULE is one of the standard mutwo module names (events or parameters or generators or utilities or converters or constants: see next section modules), e.g. karawaitan_parameters for extension mutwo.ext-karawitan
10. use VARIABLE_count to indicate the lenght of a sequence (e.g. pitch_count = len(pitch_list))

mutwo module name convention

• 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 block mutwo.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.

git guide

1. commits should be atomic (types of changes should be grouped together)
2. please try to follow this guide regarding commit messages