Smell/too many branches and too many statements

[douglasessousa]

refactor: Reduce number of statements and branches in key functions

This PR addresses two of the main code smells identified by Pylint: too-many-statements (R0915) and too-many-branches (R0912). Several functions and methods across the codebase exceeded the recommended limits, which made the code harder to read, more difficult to maintain, and increased cognitive load – especially for new contributors. To tackle this, we applied a refactoring focused on extracting cohesive blocks into helper functions, without changing the external behavior of the system.

For too-many-statements, blocks of code with well-defined responsibilities – such as data formatting, message sending, and error handling – were moved to private methods, reducing the size of the original function and making each part more self-explanatory. For too-many-branches, nested conditionals and loops with multiple exit points were simplified, and parts of the logic were delegated to specialized functions, reducing the number of branches in the main function. Concrete examples include the apply_infraction method, which went from 96 to about 40 statements, and the on_guild_channel_update method, whose branches were reduced from 13 to 6. Other occurrences were also addressed in the filtering, utils, and recruitment modules.

As a result, cyclomatic complexity (as measured by Radon) decreased, the code became more modular and compliant with Pylint's best practices, and the business logic remained unchanged. The refactoring was validated against the project's test suite, ensuring that no behavior was broken – all existing tests continue to pass locally. The changes are purely structural and do not affect the public API. This PR complements the work done by @saviosoaresUFC on reducing instance attributes, completing the treatment of the three major code smells identified in the initial analysis.

[shtlrs]

Hi - Thanks for taking the time to do this.

Can you please make sure your commit history is clean before I review this ?

Each commit should pass the linter individually, which isn't the case right now.

Commit messages should describe what you're trying to achieve, instead of just f. Descriptions that add additional contexts of why a change is taking place is also a big plus.

Also, can you please favor a rebase over merge commits ?

[jb3]

Hi @douglasessousa, we'll be closing this PR. We can see this is related to #3529 opened by @saviosoaresUFC, and the same concerns apply here:

1. We ask that contributors discuss proposed changes with the team before opening a PR — especially for large refactors like this one. Please come and talk to us in #dev-contrib on our Discord server before opening work like this.
2. Per our contributing guidelines, we ask that you don't open a pull request unless you've been assigned to an issue for it first.
3. Our linting setup is intentionally tailored to the code quality standards we want to achieve. too-many-statements (R0915) and too-many-branches (R0912) are not rules we have enabled. If you think we should enable them, please talk to us in #dev-contrib first.

If you'd like to contribute in the future, please come and introduce yourself in #dev-contrib on our Discord server and we can help get you started on the right foot with an issue that we need implementing.