Contribution Guidelines

Coding style and naming conventions

Code style and Checks before raising PRs

Module Properties

• No hardcoding
• Dynamic support to change properties

Style

• Core logic should be in Detail class
• No declarations in .h file - only base class methods overriding is allowed
• Use mCamelCase
• Format the code using ctrl+shift+I
• No unused variables, unused header files
• No Commented Codes
• If any Detail class variable has to be accessed in module, don't use set, get - make the variables public

Performance

• No memcopy unless it is unavoidable
• Initialize everything in init
• Destroy everything in term
• Use object pool for temporary variables

Unit Tests

• Test for each supported color format
• If output is image - use saveorcompare
• Always use FileReader as input for transform modules
• Use step rather than pipeline.run_all_threaded()
• Test for dynamic change of props and validation
• Use external sink module wherever applicable
• Unit test should not have sleep

Naming conventions

Name modules classes as follows

[Name][Src/Xform/Sink]{_OptionalPlatform}

e.g.

• AudioRecordSrc
• AffineXform_NPPI
• etc.

A platform variant should be created in very rare scenario. As far as possible we should try to

1. Consolidate all platform variants into a single module
2. Offer a common interface
3. Learn the users intentions via input/output pins or have explicit option about which variant to use.

Name modules properties as follows

Module properties should be named exactly like this: <ModuleName>Props. This will be used in automation very soon

Step to Contribute to ApraPipes :- External Contributors

• Make your own fork
• Create a new branch for every feature/module
• Fetch from main repo and merge to new branch
• Push new branch to your fork
• Make new pull request (PR) from the branch

Step to Contribute to ApraPipes :- Apra Labs Contributors

• Contact code owners to be added as a collaborator
• Pick up an issue / create an issue and assign it to your self
• Create a branch from main repo and push your changes in the branch
• Create pull request from the new branch and assign a reviewer.
• Update branch from main whenever needed
• After all checks pass feel free to merge your changes to main

Doxygen Documentation Guidelines

• Doxygen Official Documentation

• Commenting Basics:

  • Comment should be written using the Doxygen style.
  • Use descriptive and meaningful comments to explain the purpose of functions, classes, variables, and complex logic.
  • Comments should be concise but informative, providing enough context for someone unfamiliar with the code to understand its functionality.
  • If any generative AI is used to create the comments, use it as a base to setup and then edit / clean up. Usually gen AI comments are local / superficial, so you will have to make sure the idea is described clearly.
  • Make use of Doxygen tags for all functions and classes. This should not be skipped.

• Doxygen Tags:

  • Doxygen uses special tags to recognize comments and generate documentation. Some common tags include:
    • /** ... */ for documenting functions, classes, and variables.
    • @brief for providing a brief description of the item being documented.
    • @param to describe function parameters.
    • @return to describe the return value of a function.
    • @code ... @endcode to include code snippets within comments.
    • @note for additional notes or remarks.
  • Begin each function with a Doxygen-style comment block. For example -

  /**
   * @brief Calculate the sum of two numbers.
   * @param num1 First number.
   * @param num2 Second number.
   * @return Sum of num1 and num2.
   */
  int add(int num1, int num2);
  

• Documenting Variables:

  • Use Doxygen-style comments to document important variables, especially if their purpose is not immediately clear from their name or context.
  • Describe the variable's purpose, data type, and any relevant details.

  /// Radius of the circle.
  double radius;
  

• Contributors Responsibilities:

  • Raising a PR for a New Module:
    • Provide an overview comment at the beginning of the module file, describing the purpose and functionality of the module.
    • Add brief comments for each member functions and member variables.
    • Follow the above guidelines and add comments for all the necessary functions and variables.
  • Raising a PR for an Existing Module:
    • Add comments for updated as well as existing functions.
    • Follow the above guidelines and add comments for all the necessary functions and variables.

• References:

  • Please refer to the following link for more examples.
  • Also refer to the H264DecoderV4L2Helper for a complete module example.

• Add custom pages to the doxygen documentation:

  • Create a markdown file on the topic you want to add to the documentation.
  • Add the .md file inside data/gh-pages-assets/pages .
  • Append the path ./data/gh-pages-assets/pages/<YOUR-FILENAME>.md at the end of the INPUT tag in the Doxyfile.
  • Rebuild the documentation using the build_documentation.sh script.