Add docstring rules to Ruff linting configuration

[xiomaraR]

Description

This pull request aims to enforce docstring configuration rules for public modules, classes, and methods in the project.

Commit type

• chore

Issue

This pull request addresses #136

Solution

The solution involves modifying the lint section in the Backend/ruff.toml file to include docstring configuration rules for public modules, classes, and methods.

Proposed Changes

• Added docstring configuration rules to Backend/ruff.toml:
  • D100
  • D101
  • D102
  • D103
  • D104
  • D300
  • D419
• Ignored D100 and D103 on every file included inside the tests/ folder.
• Enforced Google-style docstrings

Potential Impact

These changes will improve code readability and maintainability by ensuring consistent documentation standards. Ignoring D100 and D103 in the tests/ folder will prevent linting errors on test files. Enforcing Google-style docstrings will streamline the documentation style.

Tests Performed

• ruff check .
• Test performed

Screenshots

N/A

Additional Tasks

N/A

Assigned

@AntonioMrtz

[AntonioMrtz]

Hi @xiomaraR , Im glad you contributed again, I wasn't sure because i didnt notice u take the issue. It helps me a lot to get track of the tasks state. The PR is good but i think we can expand it a bit if its OK to you. Now that the linter run with the newest rules i think we can make minor adjustments.

• Ignore D100 and D103 on every file included inside tests/ folder. See 1,2 for more info.
• Enforce google pydoc style in ruff.toml with

# Use Google-style docstrings.
convention = "google"

• I will colaborate on the branch by making docs for every module

I updated the issue with the new scope of the PR :) #136

[xiomaraR]

Ok, good to know. I assumed you'd be notified that I assigned myself. I'll leave a comment next time. I'll work on the new tasks soon!

Also, I don't mind updating the docs for the modules, or splitting them with you?

[AntonioMrtz]

No worries with package docs, mainly I want to do them by myself so I can represent exactly what was the original purpose of the package according to the app architecture. It will be a bit hard to make docs of some of the already existing packages. Tho I appreciate your willingness to help :).

[AntonioMrtz]

If you dont mind I will be pushing module docs to your forked repo so we can unify the PR content and work on the same branch.

[AntonioMrtz]

Hi @xiomaraR , package level missing docs are already pushed. The only remaining thing will be exclude the mentioned rules in tests modules

[AntonioMrtz]

All good @xiomaraR , thanks for another contribution. If you want to dig deeper into the project i could suggest issue #129. I'm planning on rethinking backend tests pipelines, they only work if the branches are being created directly on the base repo because of enviroment variables. Soon I will use mongodb mock for mocking a database instance for BLOB architecture tests.