Skip to content

Refactoring guidance

Freya Gustavsson edited this page May 6, 2024 · 4 revisions

utils.py

With PR 1131 being merged we have officially started work on refactoring our catch-all utilities file into a module. The initial change moved utils.py to utils/__init__.py to symbolize the beginning of this refactoring process.

To continue refactoring in a good way we have some guidelines that will make refactoring better over time as doing it all in one go is unfeasible.

General code changes with refactors

If you are modifying a file that makes use of a utils method of class that could be moved to a module. Do not move and change that piece of code into a utils submodule. This would be out of scope and means we have to review two changes in one PR. Instead, if you want to modify this please create a follow-up PR that addresses the refactor

Complicated refactors or refactors that change functionality

When a refactor will require a huge change in the codebase, one solution to address this is to keep the existing solution in utils/__init__.py and create the refactored solution in a submodule. However, please modify the existing solution with an indication to not use it.

Note

This is something we can fix in a separate PR to indicate that future uses or line changes that use the wrong function or class should fail the pre-commit linting

Likewise, if a refactor isn't that big but changes functionality you should keep the existing functionality and introduce an indication to not use it for future changes

Tracking progress

Once utils/__init__.py is as small as possible, the refactoring is considered complete