hero123457/uhd
1
0
Fork 0
mirror of https://github.com/EttusResearch/uhd.git synced 2026-10-25 17:36:10 +00:00
Code Issues Projects Releases Wiki Activity

docs: Update coding guidelines (C++ guidelines, git messages)

Browse Source 
- Added reference to the C++ Core Guidelines
- Rephrased some of the git commit message guidelines and fixed a bad
  example (was not using imperative mood in the commit message)
This commit is contained in:
Martin Braun 2017-11-06 09:53:43 -08:00
parent 7fe9973f76
commit 0adacaa252
1 changed files with 12 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
CODING.md
View File

@ -35,6 +35,8 @@ helpful move for the team and future maintainability of the UHD codebase.
## C++-specific Guidelines
* If in doubt, consult the [C++ Core Guidelines][https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md].
If the guidelines have an answer, and it works for you, just pick that.
* Use Doxygen doc-blocks copiously.
* All things equal, prefer standard C++ constructs over Boost constructs (see
also Boost guidelines).
@ -123,14 +125,16 @@ std::map<std::string, std::string> bar =
* In this repository, we almost always use fast-forward merges, and no merge
commits.
* Prefix all commit messages with the section of code they apply to (Example:
"x300: Fixed overflow at full moon"
* Keep the subject line of a git commit short and concise (so that
`git log --oneline` is actually useful), and follow up in greater detail in
the body of the commmit message. The body is separated from the subject line
with one blank line.
* Avoid long lines in commit messages (standard is 50 characters for subject,
and 72 characters for body).
* Prefix all commit message subject lines with the section of code they apply
to, and use the imperative mood (Example: "x300: Fix overflow at full moon").
Try and keep the subject line to 50 characters, but make 72 characters a hard
limit.
* Follow up in greater detail in the body of the commmit message. The body is
separated from the subject line with one blank line. Consider the body of the
git commit an email to the future reader of this changeset, so don't be
sparse in the commit body, and use it to explain the *what* and *why* of this
commit (the "how" part should be obvious from the code change). Lines should
be limited to 72 characters.
* Avoid refactoring, whitespace cleanup, or fixing code to match coding
guidelines in the same commit as modifying behaviour. Prefer dedicated
cleanup commits.