diff options
author | David Neto <dneto@google.com> | 2019-09-07 12:52:37 -0400 |
---|---|---|
committer | David Neto <dneto@google.com> | 2019-09-07 12:52:37 -0400 |
commit | 291037172dcb79318a7d0214a194e985c9ad0d7b (patch) | |
tree | d58a7039f474073fcf1bbe32a958c55252f723c5 /DEVELOPMENT.howto.md | |
parent | b93cb2bdda93ed98f253b75a59582780c8460cc1 (diff) | |
parent | 6527fb25482ee16f0ae8c735d1d0c33f7d5f220a (diff) | |
download | effcee-291037172dcb79318a7d0214a194e985c9ad0d7b.tar.gz |
Merge remote-tracking branch 'aosp/upstream-master' into update-effceeHEADndk-r27-rc1ndk-r26dndk-r26cndk-r26bndk-r26-rc1ndk-r26-beta1ndk-r26ndk-r25cndk-r25bndk-r25-beta4ndk-r25-beta3ndk-r25-beta2ndk-r25-beta1ndk-r25ndk-r24-rc1ndk-r24-beta2ndk-r24-beta1ndk-r24ndk-r23cndk-r23bndk-r23-beta6ndk-r23-beta5ndk-r23-beta4ndk-r23-beta3ndk-r23-beta2ndk-r23-beta1ndk-r23ndk-r22-beta1ndk-r22ndk-release-r23ndk-release-r22ndk-r27-releasendk-r26-releasendk-r25-releasendk-r24-releasemastermainbusytown-mac1010-release
Includes:
6527fb2 Fail parsing checks if var def regexp is bad
0eb6499 Fail parsing checks if the regexp is bad.
ecbc165 Add effcee-fuzz
3842fdc Add Bazel build rules.
4bef5db Require Python 3
8bf4e0a Add Clang warning -Wextra-semi
Change-Id: If24758e51cfcc12826dd97550429502441d769e9
Testing: checkbuild.py on Linux
Diffstat (limited to 'DEVELOPMENT.howto.md')
-rw-r--r-- | DEVELOPMENT.howto.md | 49 |
1 files changed, 25 insertions, 24 deletions
diff --git a/DEVELOPMENT.howto.md b/DEVELOPMENT.howto.md index ce2afdd..6f066c4 100644 --- a/DEVELOPMENT.howto.md +++ b/DEVELOPMENT.howto.md @@ -1,54 +1,55 @@ # Developing for Effcee -Thank you for considering Effcee development! Please make sure you review +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 +Incremental build after a source change can be done using `bazel` or `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). +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. +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? +* *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. +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. +* 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 |