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

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.
Example of GitHub subscription for one of COXIT projects.
  • 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Iryna Mykytyn

Iryna Mykytyn

18 Followers

Computer programmer specialised in C++ and the Linux OS . Passionate about coding, technologies and learning new tools for optimisation and performance analysis