We follow some guidelines for the projects when we are developing them.
We use the GitFlow development protocol.
Unless not specified by the client, our code uses the latest version of the libraries and languages we use in the projects. We don’t change the major o minor version of the libraries during the lifespan of the project, but we do use the latest patches that solve bugs when available.
We try to write good commit messages for our changes in the code. The messages should be relevant, short and point objectively what changes were made. Any programmer should understand the changes in the code with a quick read of the commit.
We follow the Google style guides for our code: https://google.github.io/styleguide/.
In general we try the code to be simple and concise:
We have default templates for the code style for IntellJ Idea. Feel free to add the new ones you need after reviewing them within your team.
All code must be documented and easy to understand for any member of the team:
Python code must include stubs in order to help the ide for the autocompletion and semantic checks.
The code under
src/ must contain unit tests for most important parts for their intended functionality.
For Python we use unittest.
We create pull requests when we want to submit anything to the master branch. This way, the notifications by email will tell us about new papers, experiments, or coded changed.
All pull requests must be reviewed at least for one member of the team. For this reason, we prefer creating small Pull Requests).
When creating a Pull Request you must include:
We must never push to master directly. All the code in master should have been reviewed before for any other member of the team and be free of bugs that prevent other members of the team to execute the code without issues.
We prefer to squash merge instead of a normal merge. Only do a normal merge if you want to keep the history of changes in our branch. After a Pull Request is merged, you should delete the related Git Branch.
When reviewing the code don’t forget to check the considerations described in code style, documentation and unit testing sections. You have a more detailed description of how to do pull requests reviews in the google’s guideline.
All our Pull Requests and Git Branches follow the next name convention:
bug/for code fixing
hotfix/for critical, out-of-cycle releases into production
other/for random tasks
We use GitHub and a file called CODEOWNER in order to assign the reviewers automatically in every pull request.