# Development Guide
If you want to contribute to this project, please fork the repository, create a new branch, make changes, and submit a merge request (MR) for review and merge.

If you have a larger feature project in mind, please contact a senior developer to discuss the best approach and implementation.

## GIT and MR guidelines

1. **No direct pushes to master:** Please create a new branch for each feature and avoid pushing directly to the master branch.
2. **Split large projects:** Break down large projects into smaller, manageable pieces by creating multiple branches and submitting separate merge requests (MRs).
3. **Assign an Assignee:** When creating an MR, assign a team member (not yourself) to review and merge the changes.
4. **Add a Reviewer (optional):** For larger changes, consider adding an additional reviewer to provide feedback and approval before merging.
5. **Merge criteria:** MRs will be merged once all reviewers have approved the changes, the pipeline has passed, and the assigned team member has merged the changes.

## Some coding guidelines

1. **Coding Standards:** Please adhere to the PARALLAX [coding standards](https://gitlab.mpcdf.mpg.de/phoenix/parallax#coding-standards)
2. **Python Modifications:** Note that some modifications to the coding standards specific to Python code will be applied, and a complete list is still being developed.
3. **Guidance on Coding Standards:** Don't worry if you're not familiar with the coding standards initially. Once you submit a merge request (MR), the assigned team member and reviewers will help you implement any missing standards and ensure your code meets our requirements.

### Code Readability and Documentation

To ensure your code is readable and maintainable, please follow these guidelines:

**Readability:** Make your code easy to read by:

- Adding spaces around operators
- Using newlines between larger logical code blocks
- Breaking up long lines of code
- Using functions for reused code
- Using clear and descriptive variable names

**Documentation:** Add documentation to your code by

- Including a comment block at the beginning of each function, class, or method to describe its purpose and arguments
- Avoiding over-documentation, which can make the code harder to read
- Focusing on explaining why the code was written a certain way, rather than what it does

**Variable Naming:**

- Use clear but concise variable names, avoiding conflicts with built-in types or functions.
- For example, integral could be renamed to integ to avoid conflicts with the int type.

**Code Lines:**

- Keep lines of code under 80 characters, using line breaks (`\`) as needed.
- Avoid more than 1 empty line at once

**Code Duplication:**

- Avoid duplicating existing code by using library routines whenever possible. Exceptions may be made if performance is critical.