To do before C++/Linux project first release (Part 1).

Here is a check list of steps which should be done in pre-release stage of any С++ project. Do it before it is too big!

STEP 0: Before start coding, set up the process!

Imagine you have a team of 2–3 C++ developers, and you are starting a new project from the scratch in a week or two. The first thing you need to do is to establish a process of code delivery and code writing rules. Remember — no rules is also a rule, it will be much harder (read expensive) to get a team used to new rules in the middle of the project, and without rules it will become messy already in a few weeks. Here is what I propose to do:

• Create a repo on GitHub/GitLab/Bitbucket, and add your team members there.
• Subscribe to this repo in your team’s Slack channel to receive notifications about all commits, new pull requests, comments, etc. Read here how to do it for GitHub. I’m not sure if it’s supported by other code hosting systems, if it is not, then this is the good reason to pick GitHub.
  Here is an example of notification about new PR.

• Choose Code Style and create README.CodingStyle file with info about chosen code style, for example pick Google C++ Code Style. Leave reference with short description of why everybody should stick to it. You can also establish some custom coding rules in that file, for example add another check list which reminds to use smart pointers, but make sure it doesn’t conflict with referenced code style.
• Set up proper Linux projects file structure. Read this article to see what I mean by proper structure: C++ application development ( Part 1 — Project structure )
• Set up the Pull Request (PR) process with your team:
  [+] Never push to master (also restrict access for everybody to do it in repo Settings).
  [+] Work on a separate branch for every new issue/bug fix/feature.
  [+] Carry about commit names: bug fixcommit message is bad one, not acceptable, Fixes bug in parsing "register" command. is better. If too much minor-change commits squash it.
  [+] Write unit tests and measure code coverage! (This will be described in part 2).
  [+] Build project and run tests successfully locally before making a PR.
  [+] Create PR with clear name and description, which answers the question: What does it add to the project?
  [+] Add youк team members as reviewers, and yourself as Asignee to the project. Don’t merge your PR before it gets at least one approval.
• Create a checklist with all above rules and add it as a template for PR, so it will be a reminder for everybody on each new PR.

As a project owner or team lead you should make sure everybody follow the process. After few weeks your team will get used to it, and it is where the process is set up.

Next step should be automating rules check up with help of different CI tools and services. Let’s discuss it in Part 2 of this article.

What rules do you practice in your team? Write in comments.