1. Git

1.1. Preparing pull request

1.1.1. Never use tabs

Don’t use tabs in code. How they are interpreted depends on the IDE/environment so everybody will see different picture. Mixed with the spaces makes code completely unreadable.

Here is a list of coding style guides of few projects:

  • Qt Spaces, not tabs!
  • Google Do not use tabs in your code
  • LLVM In all cases, prefer spaces to tabs in source files
  • Boost use spaces instead of tabs
  • Mozilla No tabs
  • KDE No tabs


According to Developer Survey Results 2017:

Well, 42.9% of developers use tabs. And 37.8% think that group is wrong.
(38,851 responses)

Heh :) Inserting spaces on pressing TAB Highlight tabs in text editor Removing tabs from file

  • Use sed -i 's,\t,  ,g' main.cpp on Linux
  • Use gsed -i 's,\t,  ,g' main.cpp on OSX
  • In gVim you can execute :%s,\t,  ,g command

1.1.2. Remove trailing whitespaces

Trailing whitespaces doesn’t change code execution flow, may be not visible to user but add additional mess with the diffs.


In Xcode trailing whitespace will not be trimmed on file save if it’s in the same line with the cursor.

1.1.3. Check there is a new line at end of file

You can see this warning while creating GitHub pull request:


Please fix this warning by adding new line at end of file.

1.1.4. Set your copyrights

Usually there is a copyright note at the top of the source file. Please add your name there. Update year if necessary.

For C++ code:

// Copyright (c) 2015-2016, Ruslan Baratov
// All rights reserved.

For CMake code:

# Copyright (c) 2015-2016, Ruslan Baratov
# All rights reserved.

For RST documentation:

.. Copyright (c) 2015-2016, Ruslan Baratov
.. All rights reserved.

1.1.5. Keep git commit’s summary short

Long summary makes output of git branch -vv looks bad:


Same with the git log --pretty=oneline output.

On GitHub summary can be used as a topic of the pull request. So it will looks ugly too:


1.1.6. Margin 80 characters

Keep each line of the code so line length is 80 characters maximum.

  • For gVim you can highlight margin using join command, see vimrc example
  • This rule can be ignored for hyper-links

1.1.7. Keep each commit as trivial as possible

Keep your commits as trivial as possible, do not mix non-related changes in one commit. For example:

  • Do not mix renaming of variable with changes in logic - make two commits:
  1. rename variable
  2. apply other changes
  • Do not rename file and do change of it’s internals - make two commits:
  1. rename file
  2. change internals
  • Quite the same with big blocks of code. If block moves with a small change make two commits:
  1. move big block only
  2. change code in block

In short keep in mind that cosmetic/trivial changes is quite easy to review (unlike logic) but they can add additional mess.

1.2. Submitting pull request

1.2.1. Pick target branch

Usually default branch is called master. If there is one more branch called develop send a patch as a pull request against it. After successful testing this branch will be merged to master.


If there is CONTRIBUTING file in repository you will see guidelines for contributing link. Please read it before submit :)


1.3. Updating pull request

1.3.1. Notify

Please note that when you’re updating pull request (by doing git push origin <branch-linked-to-pr>) no notification will be send to anybody notification will be send but it’s not clear is the pull request ready or it’s just a part of work-in-progress update. So to avoid confusion when you’re done leave the “ping” note, like Updated!.