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:
Spaces, not tabs!
Do not use tabs in your code
In all cases, prefer spaces to tabs in source files
use spaces instead of 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)
188.8.131.52. Inserting spaces on pressing TAB¶
184.108.40.206. Highlight tabs in text editor¶
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.
gsedon OSX) to remove trailing whitespaces
- In gVim you can execute
:%s, \+$, ,gcommand
Xcodeyou need to activate “Automatically trim trailing whitespaces” with “Including whitespace-only lines”
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.
gVimyou can highlight margin using
joincommand, 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:
- rename variable
- apply other changes
- Do not rename file and do change of it’s internals - make two commits:
- rename file
- change internals
- Quite the same with big blocks of code. If block moves with a small change make two commits:
- move big block only
- 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
develop send a patch as a pull request against it.
After successful testing this branch will be merged to
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. Updating pull request¶
Please note that when you’re updating pull request
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