How we do code review at Dwarves Foundation.
Every project member must have another team member or team leader to review his/her code, and every changes to the code must be achieved via a Pull request to the main development branch. On larger project (10 developers+) we may requires 2 reviewers. All of this is to ensure correctness, quality of the code and learning opportunities for both assignee (who develop) and reviewer.
We review everything on the Pull request - code, tests, documents, config files, .etc.
fmt.Print/.etc unless you have a good reason for it
.envfiles for example), unless you have a good reason for it
We don't follow TDD, we don't need to have tests for everything but we must have test to cover critical parts of the application. Test cases ensure that our app is working and without bugs whenever we introduce new features into it. Test cases also gives us the affordance to refactor and improve our code quality. With refactoring, we learn better coding practices and improve ourselves as a coder.
This topic varies depends what programming language we use as each language have their own best practices, but a general rule is to make it clear about our intention - ie. if you have no idea what a particular variable is for while reviewing a helper function, then that variable needs more comments or a new name to better reflects it's intention.
Every class and method should only do one thing. We should not lump every logic and responsibility into a God class or a super method. This makes code difficult to understand and hard to change.
There are more, but we try to only put important items in this section, the rest would be better explained/introduced during coding/reviewing while working with your team.
Drop us a message if you’d like to build with the Dwarves.Let’s build