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.