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 -
  ```cpp
  /**

  • @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.

```cpp
/// 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.