Introduction

To mantain a code style in the project we define guidelines for each programming language involved. These rules defines best practice and methods for each aspect of a program written in that language. For example, the guidelines cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, etc.

Some examples of these guidelines can be found in Programming.

We suggest two ways of check the code style in a project, Linters and Code Reviews.

Linters

You can use linters tool to verify code style guidelines. If you are in doubt about which tool you should use, refer to each language guidelines page. e.g:

Commit Hooks

You can use commit hooks to verify the code style guidelines and the commit message by overriding the following files .git/hooks/pre-commit and .git/hooks/commit-msg respectively. Have a Commit Message guidelines is important to track the changes in your repository. For example, you can define the following regular expresion to validate your messages: /#: A-Z*/ (i.e #555: Fix typo in guideline). You may find this article useful. You can check out this article to learn more about Git hooks.

In Sophilabs, we recommend configure the linters execution with git hooks using gilp.

Code Review

A code review is the process of manually inspecting source code written by another person. It allows us to find errors that might have been overlooked by the original author, and it does so at an early stage. Code reviews are not only for finding errors though; reading code written by someone else can improve our own skills and knowledge.

Process

As the developer 1

We use Gitlab or Github to manage our code reviews. We’ll be referring to Gitlab from now on since it’s what you’ll be using most of the time, but they’re fairly similar.

Every time you push changes to your branch Gitlab will allow you to open a code review to merge those changes onto a branch of your choice (usually dev, but it will depend on the project you’re working on). You get to choose the reviewer as well, typically your team will instruct you on who to choose.

After the reviewer finishes, they will either merge your changes or add comments (you will see these comments in Gitlab) to your code, probably requesting to change/fix something. Some people prefer to simply talk to the developer instead of adding comments, which is also fine. In the case you receive feedback, you will need to make the necessary changes to your code and push your branch again; Gitlab will automatically update the code review so the reviewer sees the latest version of your code.

Tips