[Tracker] Improve Code Documentation

[eprikazchikov]

📌 Description

This issue aims to enhance the code documentation coverage in the Thunder Engine repository by adding comments to public APIs within the modules and engine directories. Good documentation is crucial for developers who use or extend the engine, making APIs understandable and easier to work with.

Currently, many classes and methods may lack proper comments, which are the standard for generating the official documentation. This task involves identifying these undocumented public interfaces and writing clear, concise comments for them.

🎯 Why This is a Good First Issue

• Low Barrier to Entry: The task focuses on reading existing C++ code and writing descriptive comments, requiring no deep changes to the engine's architecture.
• High Impact: Your contribution will directly improve the experience for every developer who uses these modules in the future.
• Great Learning Opportunity: It's a perfect way to explore the engine's modular structure and understand how different components interact.
• Well-Scoped: You can start with a single header file or a specific class.

🔍 What Needs to Be Done

1. Navigate to the source code, primarily in the modules/ and engine/ directories.
2. Look for public classes, methods, and enumerations in header files (.h) that have little or no QDoc-style comments.
3. Add comprehensive QDoc comments to these public APIs. Focus on explaining:
   • What the class/function is for.
   • How to use it (parameters, return values, brief examples if trivial).
   • Any important notes or warnings.
   • Any code examples are welcome.

🚀 Steps to Contribute

1. Fork the repository and clone it locally.
2. Read the project's CONTRIBUTING.md guide for general workflow.
3. Add QDoc comments to undocumented public APIs in your chosen area.
4. Verify that your changes compile (a simple local build check).
5. Create a Pull Request with a clear title, e.g., "Docs: Add API comments to Transform".

🆘 How to Get Help

• If you're unsure about the purpose of a specific class or function, ask in a comment on this issue.
• Refer to the Qt's QDoc Manual for detailed syntax.
• Look at existing, well-documented files in the repository (e.g., check files with recent documentation commits) for real-world examples to emulate.

💡 Notes for Contributors

• Focus on the Public API: Prioritize classes and methods exposed to game developers. Internal helper functions or implementation details in .cpp files are a lower priority.
• Clarity over Completeness: A brief, correct description is better than a long, ambiguous one. If an function's use is very complex, a simple one-line \brief is still a valuable improvement.
• Check for Existing Style: Look at other documented parts of the codebase to match the tone and detail level used by the project maintainers.

📚 QDoc Comment Style (Example)

Thunder Engine uses QDoc, the Qt documentation tool. Please follow this style

/*!
 * \class Transform
 * \brief The Transform component stores position, rotation, and scale of a scene object.
 *
 * This is a fundamental component attached to every Entity. It defines its
 * location in the world space.
 */

class Transform {
public:
    /*!
     * Sets the world-space position of this entity.
     * \param position The new coordinates as a 3D vector.
     */
    void setPosition(const Vector3& position);

    /*!
     * Returns the combined world transformation matrix.
     * \return A 4x4 matrix representing the position, rotation, and scale.
     * \note The matrix is recalculated only when the transform is dirty.
     */
    Matrix4 getWorldMatrix() const;
};

[Shree1194]

"Hi @eprikazchikov! This is a fantastic initiative to improve the engine's accessibility. Since this is marked as a good first issue, I’d like to help structure the workflow for potential contributors:
Picking a Module: To avoid overlapping work, contributors should comment below with the specific file or module (e.g., engine/src/core) they intend to document.
QDoc Best Practices: While the example provided is great, contributors should remember that \brief is the most critical part for the generated API reference.
Build Check: Even though we are only adding comments, please ensure the project still compiles to avoid any accidental syntax errors in header files.
I'm excited to see the API documentation grow! If anyone needs help understanding a specific C++ class before documenting it, feel free to ask here."