You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The primary goal of this project was to enhance the Invesalius3 codebase using type information. This involved using developer such as a static type checkers, formatters, linters, and others, with the ultimate aim of better readability and developer experience.
The goals can be listed technically as follows:
Add required typing information which includes:
Adding type hints directly to functions and classes.
Writing Stubs for written Cython packages and 3rd party packages such as WxPython.
Refactoring snippets of code to comply with static type hinting.
Integrate MyPy or other static type checkers into the testing and workflows of the repository through a GitHub Action.
Integrate Ruff for linting and formatting.
Integrate pre-commit for better developer experience and better robustness.
Integrate a workflow that uses pre-commit with GitHub Actions.
Upgrade project setup by writing a pyproject.toml.
Achievements
Over the course of this project, I accomplished the following:
Development: Added type hints to the major parts of the codebase introducing wx-stubs when needed and also properly integrating all of the above technologies such as Ruff and MyPy.
As of the final submission, the project is still has some work to be finished. Mainly the following modules/packages still have to be type-hinted:
invesalius/project.py
invesalius/control.py
invesalius/reader/
invesalius/segmentation/
invesalius/net/
invesalius/navigation/
invesalius/data/ except converters.py, coordinates.py, polydata_utils.py, vtk_utils.py, and watershed_process.py
Challenges and Learnings
During the project, I learned several lessons, including:
Writing Maintainable Code: One of the key challenges was ensuring that the code I wrote was maintainable and easy for others to understand, especially in a repository with many developers working simultaneously. I learned the importance of following best practices in code organization and readability, which is crucial for collaborative projects.
Breaking Down Features: Another significant lesson was the value of dividing features into smaller, manageable pieces. I learned that it's more efficient to split features across multiple commits and to divide major features among different pull requests. This approach not only simplifies the development process but also makes it easier for reviewers to provide feedback and ensures that changes can be integrated smoothly.
These experiences have significantly enhanced my understanding of collaborative software development and have equipped me with valuable skills for working in a team-based environment.
The text was updated successfully, but these errors were encountered:
Project Goals
The primary goal of this project was to enhance the Invesalius3 codebase using type information. This involved using developer such as a static type checkers, formatters, linters, and others, with the ultimate aim of better readability and developer experience.
The goals can be listed technically as follows:
Achievements
Over the course of this project, I accomplished the following:
wx-stubs
when needed and also properly integrating all of the above technologies such as Ruff and MyPy.Opened Pull Requests
Remaining Work
As of the final submission, the project is still has some work to be finished. Mainly the following modules/packages still have to be type-hinted:
Challenges and Learnings
During the project, I learned several lessons, including:
Writing Maintainable Code: One of the key challenges was ensuring that the code I wrote was maintainable and easy for others to understand, especially in a repository with many developers working simultaneously. I learned the importance of following best practices in code organization and readability, which is crucial for collaborative projects.
Breaking Down Features: Another significant lesson was the value of dividing features into smaller, manageable pieces. I learned that it's more efficient to split features across multiple commits and to divide major features among different pull requests. This approach not only simplifies the development process but also makes it easier for reviewers to provide feedback and ensures that changes can be integrated smoothly.
These experiences have significantly enhanced my understanding of collaborative software development and have equipped me with valuable skills for working in a team-based environment.
The text was updated successfully, but these errors were encountered: