From 3695da5fbd25aa9367cace40382270c9988dbaf6 Mon Sep 17 00:00:00 2001 From: David Neto Date: Sun, 26 Mar 2017 09:58:42 -0400 Subject: Initial commit of Effcee --- DEVELOPMENT.howto.md | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 DEVELOPMENT.howto.md (limited to 'DEVELOPMENT.howto.md') diff --git a/DEVELOPMENT.howto.md b/DEVELOPMENT.howto.md new file mode 100644 index 0000000..ce2afdd --- /dev/null +++ b/DEVELOPMENT.howto.md @@ -0,0 +1,61 @@ +# Developing for Effcee + +Thank you for considering Effcee development! Please make sure you review +[`CONTRIBUTING.md`](CONTRIBUTING.md) for important preliminary info. + +## Building + +Instructions for first-time building can be found in [`README.md`](README.md). +Incremental build after a source change can be done using `ninja` (or +`cmake --build`) and `ctest` exactly as in the first-time procedure. + +## Issue tracking + +We use GitHub issues to track bugs, enhancement requests, and questions. +See [the project's Issues page](https://github.com/google/effcee/issues). + +For all but the most trivial changes, we prefer that you file an issue before +submitting a pull request. An issue gives us context for your change: what +problem are you solving, and why. It also allows us to provide feedback on +your proposed solution before you invest a lot of effort implementing it. + +## Code reviews + +All submissions are subject to review via the GitHub pull review process. +Reviews will cover: + +* *Correctness:* Does it work? Does it work in a multithreaded context? +* *Testing:* New functionality should be accompanied by tests. +* *Testability:* Can it easily be tested? This is proven with accompanying tests. +* *Design:* Is the solution fragile? Does it fit with the existing code? + Would it easily accommodate anticipated changes? +* *Ease of use:* Can a client get their work done with a minimum of fuss? + Are there unnecessarily surprising details? +* *Consistency:* Does it follow the style guidelines and the rest of the code? + Consistency reduces the work of future readers and maintainers. +* *Portability:* Does it work in many environments? + +To respond to feedback, submit one or more *new* commits to the pull request +branch. The project maintainer will normally clean up the submission by +squashing feedback response commits. We maintain a linear commit history, +so submission will be rebased onto master before merging. + +## Testing + +There is a lot we won't say about testing. However: + +* Most tests should be small scale, i.e. unit tests. +* Tests should run quickly. +* A test should: + * Check a single behaviour. This often corresponds to a use case. + * Have a three phase structure: setup, action, check. + +## Coding style + +For C++, we follow the +[Google C++ style guide](https://google.github.io/styleguide/cppguide.html). + +Use `clang-format` to format the code. + +For our Python files, we aim to follow the +[Google Python style guide](https://google.github.io/styleguide/pyguide.html). -- cgit v1.2.3