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

  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.