1. Git¶

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

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

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.

• Use sed (gsed on OSX) to remove trailing whitespaces
• In gVim you can execute :%s, \+$,  ,g command
• In Xcode you need to activate “Automatically trim trailing whitespaces” with “Including whitespace-only lines”

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.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.

1.2.2. Read CONTRIBUTING¶

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

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!.