Contributing to the M-M.E.S.S. project

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms. Note further, that we follow Contributor Covenant and would like to emphasize the following additional examples of unacceptable behavior:

When contributing to this project, please note the following style conventions that are enforced (partially strictly enforced by the CI server).

Most importantly, reflect your changes in the Changelog so we do not have to reconstruct it from the GIT history.

Attribution

When you have contributed code to M-M.E.S.S. you and the content of your contribution will be mentioned in the project’s contributors file. Contributions are grouped by release, so if you have contributed code to multiple releases, you will be mentioned for each of these releases.

If, for some reason, you do not wish to be mentioned in the contributors file, please give us a short note. Also note that we cannot give attributions to trivial changes, such as fixing a typo in the documentation or correcting a very simple bug. However, your changes including your authorship will always be included in the git history of the project.

M-M.E.S.S. Style Guide

In general we prefer descriptive identifiers that support easier reading and understanding of the code. Other than that, follow the guidelines below:

Naming of functions:

Code Style:

Maintainability

Our GIT repository provides maximum flexibility for forking, branching, merging, and commenting on work done. For the sake of maintainability follow these guidelines:

Test Framework

We use an extensive test system on our continuous integration (CI) server to ensure that new features do not break old functionality and all features work in both MATLAB and GNU Octave, both with and without toolboxes/packages installed. Currently CI time is limited to 2 hours and all tests should be finished in that time.

We distinguish between so called unit tests and system tests. Here, unit tests are testing the smallest possible building blocks. As a rule of thumb, a routine that does not call external functions, or only private functions is a candidate for a unit test.

Larger routines that run a hierarchy of other stuff, such as our demonstrator functions in the DEMOS folder should be used to perform the much bigger system tests.